Slow commenting and general poor performance

themitchy wrote on Tue Jun 19 19:23:30 MEST 2007:

It seems to take about 2 seconds per line when commenting or uncommenting
a block of code.   Is this the performance I should expect?

The editor in general was quite slow over-all.  Turning off Smart typing
and "mark occurances" helped a little.  I can take a bit of slowdown but
this comment thing is unworkable.  Is there anything else I can disable
to speed this up?

jploski wrote on Tue Jun 19 20:25:26 MEST 2007:

How many thousands of lines of code do you have in your file and how old
is your machine? BTW, comments should not be such a big problem, it's much
worse with open quotes.

jploski wrote on Tue Jun 19 20:27:04 MEST 2007:

Oh, you are referring to block comments.. then it's the same thing as quotes
- it has to reparse the whole file as you type. There's nothing you can
do to speed things up other than split your source code into smaller files
or write a faster parser.

hingamp wrote on Fri Jan 25 19:10:51 CET 2008:

After trying to tweak EPIC preferences for quite a while, I finally find
the cure for >5 seconds editor hangs whenever I open quotes or add comments:
split my code... A real shame as the plugin is brilliant with small bits
of Perl scripts. Did I forget to mention my scripts are over 3500 lines...
Shame I know, but it easier to forget EPIC and open them with gedit than
to recode thousands of lines of working code:) My machine is not to blame
(two dual core 64b 3.2Ghz procs with 2Gb RAM), Eclipse SDK Version: 3.2.2
EPIC 0.6.18

jploski wrote on Fri Jan 25 19:21:02 CET 2008:

For quotes the automatic quote insertion (Smart typing in Perl EPIC/Editor
preferences) does the trick (when deleting quotes, delete both of them to
avoid delays). Tough luck with block comments, though.

jploski wrote on Fri Jan 25 19:23:46 CET 2008:

Also, I have a 7000+ lines file and inserting a quote takes under 2 seconds.
This is still painful, but I guess you are exaggerating a bit?

hingamp wrote on Fri Jan 25 19:17:05 CET 2008:

Is there any chance that us thousand-perl-liners could benefit from 'just'
the syntax highlighting and outline functionalities and really completely
disable everything else? The current Preferences seem to change nothing
including the 'Validate source when idle for' delay or checkbox (I guess
the slow process isn't source validation).

jploski wrote on Fri Jan 25 19:26:29 CET 2008:

It's "just" the parser (responsible for syntax highlighting) which is slow.

hingamp wrote on Fri Jan 25 19:20:14 CET 2008:

I even tried tricking EPIC by providing a mock Perl executable that always
returns "- syntax OK" - that's how desperate I am....

hingamp wrote on Fri Jan 25 20:07:52 CET 2008:

Understood.

However how come the "gedit" or "kate" or "emacs" syntax highlighters are
so fast that I never notice any delays whatsoever (on the same huge monolithic
perl files)? Because they only update the color on the current line? or
is it to do with Java versus compiled binaries?

I could try the automatic quote insertion, but I get the same hangs with
just inserting a "#" comment (not block comments). And honestly, I'm not
exagerating with the delay duration. If I could do it easily I'd record
a film of it happening. 

jploski wrote on Fri Jan 25 20:43:45 CET 2008:

They have faster, though less powerful lexers (the ANTLR used by EPIC is
not optimized for real-time parsing). They restrict syntax highlighting
to a range - but so does EPIC. However, your mention of '#' being slow is
intriguing. It appears that typing a # causes EPIC to lose track of a "synchronization
token" in the current line, so that it unnecessarily reparses the entire
file. I think it can be fixed.

As for the delays, it may be a good thing to open a bug report and upload
your worst offending file so that I can perform actual measurements on it.
My canonical test case is Twig.pm, which you can get from CPAN - over 11000
lines. As posted previously, typing is slow, but nowhere close to the 5
seconds mark you mentioned.

jploski wrote on Fri Jan 25 20:55:29 CET 2008:

Regarding the # slowness, see https://sourceforge.net/tracker/index.php?func=detail&aid=1879954&group_id=75859&atid=545274

I'm releasing 0.6.19 with this fix.

hingamp wrote on Fri Jan 25 21:33:43 CET 2008:

In fact I found a way recording my desktop: http://biologie.univ-mrs.fr/out_a.ogg
I can't leave that film up there very long, do let me know when i can take
it down...

In fact I was underestimating by an order of magnitude the EPIC editor slowness:
-opening a 3445 line Perl script takes a full 30 seconds (ok, I can deal
with that once a session)
-inserting the single # character takes, not 5 seconds, but again a full
32 seconds!
-the video shows comparison with the ECLIPSE simple Syntax Coloring Editor
(slow opening but instant editing!)

Many thanks for your patience and for taking this "comment" up so quickly!
Pascal

jploski wrote on Fri Jan 25 22:05:13 CET 2008:

Shocking. If you send me the file, I will check how long it takes on my
humble 2.8 GHz P4.

jploski wrote on Fri Jan 25 22:09:55 CET 2008:

Which version of the Java virtual machine do you use for running Eclipse?
(Help/About Eclipse SDK/Configuration Details)

hingamp wrote on Fri Jan 25 22:23:29 CET 2008:

I'm releaved you agree I'm not exaggerating...

Java virtual machin appears to be : 

java version "1.5.0"
gij (GNU libgcj) version 4.2.1 (Ubuntu 4.2.1-5ubuntu5)

Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO



Help/About Eclipse SDK/Configuration Details:

*** Date: Fri Jan 25 22:17:54 GMT+01:00 2008

*** Platform Details:

*** System properties:
eclipse.buildId=M20070212-1330
eclipse.commands=-os
linux
-ws
gtk
-arch
x86_64
-launcher
/usr/lib/eclipse/eclipse
-name
Eclipse
-showsplash
600
-exitdata
67c002b
-install
/usr/lib/eclipse
-vm
/usr/lib/jvm/java-gcj/bin/java
eclipse.ee.install.verify=false
eclipse.product=org.eclipse.sdk.ide
eclipse.refreshBundles=true
eclipse.startTime=1201295848272
eclipse.vm=/usr/lib/jvm/java-gcj/bin/java
eclipse.vmargs=-Djava.library.path=/usr/lib/jni
-Dgnu.gcj.precompiled.db.path=/var/lib/gcj-4.2/classmap.db
-Dgnu.gcj.runtime.VMClassLoader.library_control=never
-Dosgi.locking=none
-jar
/usr/lib/eclipse/startup.jar
eof=eof
file.encoding=UTF-8
file.separator=/
gnu.classpath.home=/usr
gnu.classpath.home.url=file:///usr/lib
gnu.classpath.version=0.95
gnu.classpath.vm.shortname=libgcj
gnu.cpu.endian=little
gnu.gcj.precompiled.db.path=/var/lib/gcj-4.2/classmap.db
gnu.gcj.progname=/usr/lib/eclipse/startup.jar
gnu.gcj.runtime.VMClassLoader.library_control=never
gnu.gcj.runtime.endorsed.dirs=/usr/share/java/gcj-endorsed
gnu.gcj.user.realname=Pascal Hingamp,,,
gnu.java.util.zoneinfo.dir=/usr/share/zoneinfo
http.agent=gnu-classpath/0.95 (libgcj/4.2.1 (Ubuntu 4.2.1-5ubuntu5))
java.class.path=/usr/lib/eclipse/startup.jar
java.class.version=49.0
java.ext.dirs=/usr/share/java/ext
java.fullversion=GNU libgcj 4.2.1 (Ubuntu 4.2.1-5ubuntu5)
java.home=/usr/lib/jvm/java-1.5.0-gcj-4.2-1.5.0.0/jre
java.io.tmpdir=/tmp
java.library.path=/usr/lib/jni
java.runtime.version=1.5.0
java.specification.name=Java(tm) Platform API Specification
java.specification.vendor=Sun Microsystems Inc.
java.specification.version=1.5
java.vendor=Free Software Foundation, Inc.
java.vendor.url=http://gcc.gnu.org/java/
java.version=1.5.0
java.vm.info=GNU libgcj 4.2.1 (Ubuntu 4.2.1-5ubuntu5)
java.vm.name=GNU libgcj
java.vm.specification.name=Java(tm) Virtual Machine Specification
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.vendor=Free Software Foundation, Inc.
java.vm.version=4.2.1 (Ubuntu 4.2.1-5ubuntu5)
line.separator=

[snip]

Bye for now (the food is in the dog, and I'm in the dog house by now).

jploski wrote on Fri Jan 25 22:30:14 CET 2008:

I highly recommend that you try the Java version from java.sun.com and compare
the performance. Just download the non-RPM installer, run it to unpack it,
accept the license and finally run "export JAVA_HOME=/path/to/the/top/unpacked/directory;
export PATH=$JAVA_HOME/bin:$PATH; eclipse".

hingamp wrote on Mon Jan 28 14:38:59 CET 2008:

Resolved!

Well spoted Jan: I switched to Sun JAVA 1.6.0_03 and, well, it's astounding:
loading the same Perl 3K script is a few seconds and the comment insertion
delay is maybe a second!!! A full 30 times acceleration. What's this default
gcj Java?.... 

I can get back to work:) Many thanks again for your precious help,
Pascal

java.specification.name=Java Platform API Specification
java.specification.vendor=Sun Microsystems Inc.
java.specification.version=1.6
java.vendor=Sun Microsystems Inc.
java.vendor.url=http://java.sun.com/
java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi
java.version=1.6.0_03
java.vm.info=mixed mode
java.vm.name=Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.name=Java Virtual Machine Specification
java.vm.specification.vendor=Sun Microsystems Inc.
java.vm.specification.version=1.0
java.vm.vendor=Sun Microsystems Inc.
java.vm.version=1.6.0_03-b05

jploski wrote on Mon Jan 28 18:23:31 CET 2008:

Ok, thanks for reporting - it is certainly going to be a good tip for other
users as well.

gcj is GNU project's implementation of the Java virtual machine and a bytecode-to-machine
code compiler. As you can see, not so impressive performance-wise. Maybe
it ran in interpreted mode, which could have made matters even worse (though
I doubt that it did). AFAIk, Debian (and the derived Linux distributions)
have licensing issues with redistributing Sun's Java and that's why they
ship gcj as default.