I don't think this is the fault of the product per se, although there are cases where the "Connection Busy (Try Again / Abort)" appears. I tried on both a slow WinXP system and a fast Linux system. Each performed fairly well, but the the faster machine was smoother. More objects open simultaneously seemed to have an impact. Getting interrupted for a few minutes (SQL Developer may have gotten partially paged out), then resuming the test seemed to have an impact.
Did you check SQL Developer's VM Size or memory use during your session?
To get the actual Java VM heap size you would have to use a memory profiler. In a future release, SQL Developer will probably show this Java VM size at the bottom right of the main window like current JDeveloper versions do. To get a rough idea now, however, you can check ...
1. On Windows, using Task Manager, enable the VM Size column in the Processes tab and check that for sqldeveloper.exe.
2. On Linux, using "top", check the memory for the Java process that represents SQL Developer.
Because the first find is fast, I have not worried about the total number of objects in the schema or database latency. Note that find for all types does take longer than find for a specific type, but apparently that is not your use case.
I finally had time to profile this. In my case, especially when the number of objects found is large, it looks like the performance hit is related to use of Oracle Look and Feel. You can try using Tools|Preferences|Environment|Look and Feel: Windows if the prior setting was Oracle and see if that helps.
Reading over this thread, it strikes me that I was never able to replicate the described behavior with the provided test case. The procedure you give is fine, but to be complete the case description should also include the Oracle database version your connection points to, whether it's remote, the privileges your user has, and so on. By doing lots of other things, I got slower query performance but not slower name prompt performance. And, in those slower query cases, switching from Oracle to Windows look & feel really did help.
At this point you might try keeping Task Manager open and visible during the test case, with the Processes tab sorted on CPU descending. When the slow performance occurs, are SQL Developer and/or Oracle (if the DB is local) doing anything? If the culprit is a CPU-intensive SQL Developer phase, then the next step would be to do some CPU profiling (using something like JDeveloper or Netbeans) in your environment. Otherwise something must be happening on the DB end of things.
it seems I am hitting exactly the same issue as Vasanth and I can confirm that the slow down is real and very annoying.
I use latest SQLDev downloaded with its JDK and I also am using the Windows Look and Feel. I am connecting to a remote 220.127.116.11.0 database that is part of an e-Business Suite 12.1.3 instance as the APPS user (that has quite a lot of access rights).
In reality, I experience SEVERAL different cases when SQLDev slows down so much that it seems to freeze for several seconds and I am afraid that the slowdowns may be due to the huge number of objects that are owned by the APPS user (a count on user_objects gives me 170953 results).
Also I do not see any meaningful CPU usage spikes during those slow downs (I am using Process Explorer by Microsoft to monitor the tasks).
I would be very glad if I can do some more debugging and help you tracking down the issue that bugs me so much. Please let me know what else I can try to help you.