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-188.8.131.52/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.
Note: The above is an archived snapshot of a forum thread. Use the original thread at sf.net to post comments.