I accidentally blogged this…twice. Here’s the other take. This happens more often than I care to admit, sorry.
Forgive the inelegant post title – but it gets to the point, and I reckon it might be closer to what folks will be Googling.
I get questions from time to time around getting SQL Developer to load or respond quicker.
Here’s the advice/tips I generally lead with:
Look and Feel
You can tell SQL Developer to use a custom ‘look and feel’ that we ship with the product called ‘Oracle,’ or you can say, just let the Operating System take care of that.
The OS look and feel is ‘cheaper.’ It could be A LOT cheaper.
I personally prefer the Oracle look and feel on my Mac, and it runs fine with NO performance problems. My Macbook Air is from 2013, has an Intel i5 processor, with 8 GB of RAM and a 500GB SSD.
Some of you have newer, better Macs, and this preference has helped you. So give it a shot.
Most of you will probably not be working on 3rd party RDBMS migrations to Oracle. Data Miner is a popular feature, but again, many of you aren’t using it today.
You can disable these features. It means there will be less files to open, less code to load, less stuff in the UI to worry about.
Don’t go crazy here. Some of the features might include things you don’t think you use, that you actually use. But, you can always turn them back on as necessary.
Close Stuff When You’re Done
I’m mostly talking about data grids. If you query something, and then query something else, and … N -> you’ll eventually end up with several dozen tabs open. This CAN take both client and server resources. Close things when you’re done looking at them. Same goes for documents/object editors as well.
Tweaking the JVM
This is not recommended for folks that don’t know what they’re doing. But, you can give Java more memory. You can tell Java to take more memory right away. You can tell Java to handle garbage collection differently. There are many dozens of JVM flags you can set, that will impact the way SQL Developer runs and operates. You make these changes in the product.conf file.
In Windows, this will be in the AppData directory.
I would try these things, in this exact order. Try the easy things first, then worry about the JVM. Also, use a newer version of Java.
Two last things…
1. If you set your SQL History limit to something really high, it will eventually maybe cause your start-time to increase. If you set it to say, 30,000, at some point, you’ll be asking SQL Developer to find 30,000 XML files, open them, and read their contents into memory. You ask, you get. Adjust as necessary.
2. For folks running SQL Developer on Citrix or via Remote Desktop, try tuning down the graphic settings – lower resolutions/DPI type things. I’ve heard from users that this can help with the response time as well in terms of the UI drawing/reacting to mouse-clicks, etc.