Community
Participate
Working Groups
Build 3.4M4 I have a unit (GenericTypeTest) which is huge. I just edited it in various places to remove some try-catch blocks, and each time I was performing a change, I had to wait a little bit before I could select another method in outline, or a different marker in problem view (pointed at another area of the same unit). It feels that reconcile is getting in the way. I wonder if editor couldn't be more resilient to big files. For instance, maybe the reconcile delay could be made longer if the file is so big, i.e. be more dynamic, could be based on how long first reconcile took... Currently, when these delays occur, it feels like the IDE is not responsive at times, which is annoying.
We have to exactly investigate why it's waiting. Dynamically tweaking the reconciler delay might be an interesting thing to investigate.
Agreed, I cc'ed Jerome since something bad could be occurring in JDT/Core. I am suspecting that we do some linear search which are expensive once you have over 1200 methods...
From my investigations, ICompilationUnit#reconcile(...) reacts in less than 150ms in the case of GenericTypeTest. To monitor this scenario, I added a progress monitor to the reconcile operation: monitor = new NullProgressMonitor() { int count = 0; long lastIsCancelled = System.currentTimeMillis(); public boolean isCanceled() { ++this.count; int debug = this.count; long current = System.currentTimeMillis(); long time = current - this.lastIsCancelled; if (time > 80) System.out.println("isCancelled #" + debug + " took " + time + "ms"); this.lastIsCancelled = current; return false; } };
