As work around try close project view before navigation

Thanks, but that did not work until I had all the views closed (including the run window)

Do you happen to be using files on a mapped or mounted network drive, and to have "Synchronize files on frame activation" checked in the General IDE Settings? If so, you might try unchecking that, or else move your files to a local drive. This fixed a problem that caused similar symptoms for me, but I don't believe the Stack traces you attached would be caused by this.

Sorry to trouble you if this is not relevant.

All files are local. One thing that I have noticed is that even with all the views closed I will get a periodic delay of only 3-5 seconds when either switching to an open class or opening a new one.

This delay appears to go away when I click on Collapse All on the projects view. My guess is that it only takes about a couple hundred class loads to fill up 110MB of memory that will not be released until the Collapse All button is clicked.

For now I have unclicked the Autoscroll from Source in the project view. This appears to have eliminated all the delays I encounter.

When delays occur:
Click on the garbage collection (The memory status says 220M of 254M)
Click Collapse All
Click on the garbage collection (The memory status says 110M of 254M)

You should take a memory/cpu snapshot of the delay and attach to the issue.

Since enabling the CPU/memory capture, the reproducability of this issue has become non-consistant. Since the UI is locked out when it occurs, I cannot even click on the CPU capture button during the event. I have captured a memory snapshot after one of the occurances, but it is too large for uploading (60Mb zip, 42 Mb rar)

I have recently encountered another situation (only once so far), that appears remarkably similar to the original one:

The attachment 6107_Developer_18.12.2006_16.11.52.zip is a CPU capture that occurred when I deleted the second 'l' in null to cause the 'cannot resolve symbol' message to show up. In this case, the CPU races for about 5 seconds and the user interface is unavailable 2 or 3 times. Each of the UI lock outs are for only about 1/5 of a second, which is unlike the original issue where the UI is locked out for the entire duration of the CPU race condition.

Click on the garbage collection (The memory status says 239M of 254M)
The memory capture after the CPU capture was 80MB (zip), 52MB (rar), so I have not uploaded it.