The ‘Holy Grail’ of software tools is the environment where things are made easy, but not at the expense of usability or simplicity. You use a tool because it makes something ‘easier’, but some software products are anything but.
SQL Developer is fairly scaled down. You have a few toolbars, several menus, and 2 driving windows – the Worksheet and the Browser. But what if it could be even simpler? SQL Developer is asked to be the database IDE. We serve many masters, yet a majority of our users simply look to the tool to be a GUI replacement of SQL*Plus.
What if you as a user could ‘slim’ down SQL Developer? Less menu items, fewer widgets to load? A leaner, meaner SQL Developer?
Well, you can do that today.
Disable all the extensions.
This question came up at my presentation at RMOUG, and I didn’t have a great answer. Fortunately my boss was there and he had a really good answer: simply go into the preferences and disable all the extensions.
I suggest you turn off everything but the ‘SearchBar.’ Once you make a change here you will need to re-start SQL Developer to make the changes take effect. You will see two primary advantages:
- Faster load time
- Simplified UI
Ok, so the first item is purely subjective. On my WIN7x64 machine SQL Developer is loading in a little less than 10 seconds versus about 30 seconds. I’m not guaranteeing this benefit, but try it for yourself and see how it goes.
For the primary benefit, you will notice the main menu items are scaled down. No items for Source Control, the Data Modeler, Migrations, or Data Miner. These are not ‘bad’ things, but chances are you rarely use these features. You can in fact turn them off (and turn them on, as required.)
Further Optimize Your SQL Developer Experience
There are a few more techniques and preferences you can exploit to get SQL Developer running faster and using less system resources. Note that I run SQL Developer ‘out of the box’ with no tweaks and it runs just fine. However what works for many people won’t necessarily be right for everyone. Here are a few changes you can make in a few moments to dramatically affect SQL Developer’s performance.
Set Look and Feel Preference to Host OS
Look and Feel is a Java property that controls how the application’s GUI ‘widgets’ are drawn and behave. You can let the host OS control this, or you can implement your own themes. SQL Developer ships with an ‘Oracle’ Look and Feel theme. I think it’s nicer than what Windows gives out of the box for Java applications.
It costs more, CPU to be specific. It takes more work for the tool to run if it’s controlling the ‘look and feel’ instead of just farming that out to the operating system. Now the funny or weird part here is that I’ve heard a few OS X folks tell me they see the exact opposite behavior. So, if you see SQL Developer running slow or it chewing up the CPU, try switching this preference and restarting the application.
Close Grids and Files When You’re Done with Them
This is hopefully common sense. Having data loaded in a grid consumes memory. Lots of rows = lots of memory. Close the grids when you’re done. When you close a grid it forces the JVM to do garbage collection. This is fancy talk for saying that the java application will release memory back to the java virtual machine.
Don’t Set Your SQL History Limit to Some Obscenely High Value
Like 30,000. That’s too high. I think the default (100) is too low. Mine is currently set to 500. Just know that what you set it to affects memory. The SQL History data is read into memory at start up. The more you save, the more it costs.
Still Experiencing SQL Developer Performance Issues?
Drop me a line at [email protected] or leave a comment here. We’ll do our best to get your issue sorted out. Keep in mind I’ll ask you to try the above tips first, then ask you what version of SQL Developer you’re running and what JDK you’re using. Answers including anything BUT ‘Latest version and Java 6/1.6 JDK’ will be me replied with ‘try that and get back to me.’
With more than 2,500,000 active users today, Oracle SQL Developer is bound to be running in some environments that cause performance issues. We won’t be satisfied until everyone has a good of an experience with it as we do!