Gary Graham wrote:Nope
Do you have any third-party extensions installed?
Do you use source control management (like SVN)?Nope
If you wish to take multiple thread dumps, increase the console buffer size to several thousand lines."Thanks Gary. That's a fairly laborious process to get some debug out of SQLDeveloper. Is there no way to switch debugging on, launch the application and have it spit stuff out to a log?
AddVMOption -Xms50Msettings in the sqldeveloper-debug.conf file. They are lower than the non-debug settings and also might be slowing you down even more.
In my case the first launch takes 30 sec. Close and relaunch takes 5 to 6 seconds. I use 1.6.0_35.Out of curiosity, I retested this launch test immediately after booting up: it took 60 rather than 30 sec. A relaunch after the close took only 7 sec. The moral of the story? Lots of services are starting up on my system at that point and obviously have an impact. Probably something similar is true for your system.
In an earlier post you said the debug setting shows a DBConnAddin entry in the Logging Page taking all the time, but it does not make any sense that a remote database would always get really busy just after you start your machine. So I would bet that some local process (or set of processes) hogs resources or otherwise blocks after booting up. Do you have a local database starting up or some anti-virus program doing some heavy-duty checking/updating at start-up?
Number of threads sleeping on a monitor - 6 Number of deadlocks - 0 Number of Monitors without locking threads - 0 31% of all threads are sleeping on a monitor. This might indicate they are waiting for some external resource (e.g. database) which is overloaded or not available or are just waiting to get to do something (idle threads).