[DrJava] Profiling Observations

[Peter C. <cen...@ri...>]

Here's a progress report on my attempts to improve DrJava 
performance on OS X.  I've done a bit of profiling with the 
OptimizeIt tool from Borland (free trial download).  I 
discovered several interesting things:

MainFrame.updateFileTitle() was the culprit for most of the 
window updating.  This method was getting called for every edit 
keystroke, and was updating the entire window and then the doc 
list.  This code should only be executed when the title changes: 
when a modified file is saved, after a Save As, or when an 
unmodified file is first edited.  To check this, I added a new 
field to MainFrame (_fileTitle) and verify this value against 
the current title before making expensive redraw calls.  I'm 
still investigating whether it's possible to repaint an 
individual item in the JList, rather than the whole (mostly 
empty) list.

The whole editor pane is still getting updated with each edit.  
That shouldn't be necessary.  Resolving that is my next point of 
attack.

Position updating adds a serious CPU cost for general editing 
operations.  Almost all of that CPU time can be traced back to 
AbstractReducedModel.absOffset().  This method eats CPU for 
breakfast.  As far as I can tell, it is retokenizing the entire 
source file (backwards) every time the position is updated.  
After clicking around in DefaultGlobalModel for about a minute, 
the profile showed that this function had cost over half of the 
total CPU time.  That file is around 1600 lines, which is not 
unreasonable for a complex class.  I don't think that a 15-20 
second delay is justified just to update a line count.  There 
has got to be a faster way of doing this.  I recommend that 
position updating be pulled out of the main build for the time 
being until the serious performance problems in the reduced 
model are resolved or avoided.

The buildTree() method in the indenting framework is eating 
slightly over a second of CPU time on my machine.  This cost 
seems to be a one-time hit, but it's fairly significant.  It 
would probably be worth a follow-up pass on the code to see if 
some of that time can be recovered.

I plan to do a little more investigating today to see if I can 
slim things down before our next public release.

--
Peter