[DrJava] [ drjava-Feature Requests-521298 ] Speed Issues under OS X

[<no...@so...>]

Feature Requests item #521298, was opened at 2002-02-21 19:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=521298&group_id=44253

Category: Definitions (source editor)
Group: None
Status: Open
Priority: 5
Submitted By: Peter Centgraf (centgraf)
Assigned to: Peter Centgraf (centgraf)
Summary: Speed Issues under OS X

Initial Comment:
The comments for this feature request are compiled from the mailing list:

Peter Centgraf says:

I know this may not be a popular suggestion, but could we make 
it a feature/improvement project to speed up the main editor?  
Right now speed is the primary reason why I cannot use Dr. Java 
for real programming.  According to several online tests, I type 
at approximately 60 wpm.  This is certainly not expert typing 
performance by clerical standards, but it is above average.  I 
believe it is reasonable to expect Dr. Java to be able to keep 
up with this rate of input.  Unfortunately, I can type "public 
static int" in less time than it takes Dr. Java to display 
"public static" with proper coloring.  This is simply 
unacceptable.  Keep in mind that this is running on a reasonably 
up to date 500 MHz machine with all Swing acceleration features 
turned on.

For comparison, I played with various other Java text 
environments.  The plain-vanilla text box in MRJAppBuilder had 
no trouble keeping up with me.  BlueJ will fall behind if I 
pound arbitrary characters, and it is clear that some lag is 
occurring, but I was not able to produce any "stutter" in my 
text input.  By the time I raised my finger from the last letter 
of a word, BlueJ had always rendered that word.  I also played 
with JBuilder 6.  It was even more responsive.  Even pounding 
random keys as fast as I could manage, JBuilder still produced 
virtually instant response.  Both of the last two examples 
perform fairly complex syntax coloring.  I think that if they 
can do this, we can too.


Later:

I attempted the performance workaround that Brian suggested in 
class.  I commented out the entire body of the 
DefinitionsDocument._styleChanged() method and then rebuilt with 
ant.  It is hard to tell if there is any real change in 
performance.  Using the same test as before, Dr. Java was able 
to update "public static int" fast enough to start drawing "int" 
by the time I stopped typing, but it was still several 
characters behind what I was currently typing.  If I wrote a 
larger block of text, like would happen in a comment block, 
sometimes entire words of 6-8 characters would lag and seem to 
appear all at once.  It feels subjectively like there was an 
improvement, but I might also be typing slightly slower than I 
was earlier today.  The window still seems to flicker while I 
type, but I think most of that effect is caused by the selection 
on the list of open documents.  I don't think this "fix" is a 
panacea for Dr. Java's performance problems on OS X.


From Brian Stoler:

Here's another speed experiment: Try commenting out the overridden
getViewFactory() in model/definitions/DefinitionsEditorKit. This will turn
off our colored display, but it will still leave the underlying model
implementation going. So, the model will be maintained, but not the color
information will be ignored for the UI.


From Charlie Reis:

   Wow-- I can confirm the need to work on speed on OS X.  As a CCA, I 
have one of the older iBooks (the ugly orange handbag-looking thing), 
with OS X 10.0.4 installed.  Granted, it's not the fastest machine, but 
I can get done typing an entire line before it has shown the first word.
   One thing worth noting is that the Interactions pane has acceptable 
performance (it's _much_ faster than the Definitions pane).  I haven't 
tried the suggested fix, but it's worth poking around to see what can be 
done...


And the latest installment:

Commenting out getViewFactory succeeds in disabling all drawing in the definitions pane whatsoever.  Now all I get is the OS X striped-background where the definitions should be.  I'll keep investigating this, however.  I agree that it would be very helpful if we can disable the style routines only and keep the reduced model running.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=438938&aid=521298&group_id=44253