Slow(!) variables update(Europa and 0.6.13)

mjscott2702 wrote on Wed Aug 22 01:43:24 MEST 2007:

I have recently installed Eclipse 3.3 (Europa) and EPIC 0.6.13, having used
Eclipse 3.2 and whatever the most recent testing version was. While debugging
my script, the Variables display takes FOREVER to update, much slower than
what I have experienced before. True, I am expanding some very large arrays/hashes,
but this was doable in the past - not now?

Any suggestions MOST welcome! :)

wanda_b_anon wrote on Wed Aug 22 15:03:58 MEST 2007:

Ditto- Eclipse 3.3.0 and epic 0.6.13.  I do not have big arrays and hashes,
the expansion is S L O W.

mannih2001 wrote on Wed Aug 22 17:27:57 MEST 2007:

I'm afraid, I'll also have to confirm this. I updated to Europa on Monday
and didn't notice anything strange. Until today. Content assist suddenly
takes forever (and I'm talking minutes here, not seconds) and uses all the
CPU it can get. This is with Eclipse Europa 3.3.0 and EPIC 0.6.13.


Manni

jploski wrote on Wed Aug 22 19:32:47 MEST 2007:

I don't feel any slowdowns in the Variables view (as reported by Michael)
nor in the Content Assist (autocompletion):

Linux, GTK
Version: 3.3.0
Build id: I20070625-1500

Can you supply a test case to demonstrate the slowness? Preferably one which
runs with an acceptable speed in Eclipse 3.2.x. Also, what platform are
you experiencing this on - Windows?

mjscott2702 wrote on Wed Aug 22 20:50:17 MEST 2007:

I am running Windows XP SP2 on a 2GHz dual-core Centrino processor with
2GB of RAM. Running the following script in non-debug mode takes less than
1 second to print the greeting and exit.

In debug mode, it takes 10 seconds for the collapsed $tmp array to even
appear in the variables window. Expanding the array takes another 33 seconds
to complete. At that point, the GUI becomes completely unresponsive, and
I had to kill the perl process externally.

for (0 .. 10000) {
   $tmp[$_] = $_;
}

print "Hello World\n";
exit(0);

mjscott2702 wrote on Wed Aug 22 20:51:27 MEST 2007:

Sorry - Eclipse build is:

Version: 3.3.0
Build id: I20070621-1340

jploski wrote on Thu Aug 23 00:06:22 MEST 2007:

Ok, thanks for the example. This performance problem is not related at all
to Eclipse 3.3 in my opinion. Anyway, I just committed some fixes, so upgrade
to 0.6.14 and see if it's better.

wanda_b_anon wrote on Fri Aug 24 22:27:20 MEST 2007:

I am now using 0.6.14 and when I turn on Perl Epic/Editor/Content Assist/Inspect
Variables and am typing a variable starting with $ things go extremely slowly
as the pull down is populated, especially since it has the most values at
first and then winnows down. Typing echoes about 1 character per 5 seconds
or more.  

Inspect Variables would be nice to have, but it is a deal breaker when on.
 I agree this may be unrelated to eclipse 3.3, since I came back after not
using 3.3 or "inspect variables", so I turned on both at once and recall
turning off "inspect variables" in the old days.

Hope this helps.

jploski wrote on Fri Aug 24 22:34:59 MEST 2007:

Based on an example sent my mannih2001, I believe this is exclusively a
problem under Windows. If you wish to examine it for yourself, there is
a little guide out there of how to debug EPIC quickly: http://e-p-i-c.sf.net/devguide/devguide.html

wanda_b_anon wrote on Sat Aug 25 00:03:28 MEST 2007:

I would LIKE to help, but reporting the bug is as far as I be helpful. 
The link says:

"We assume that the reader is familiar with Java in general and the Eclipse
IDE (more precisely, JDT) in particular. "

and I don't know java or JDT or much of eclipse.  I came for perl...

But, hopefully someone like we need will step forward, or you will get a
windows box for testing.

No loss over where I was before...

Thanks for such prompt replies and obvious dedication.

mannih2001 wrote on Sat Aug 25 10:45:46 MEST 2007:

It's the same with me. Guess I'm pretty good with Perl, but Java and Eclipse?
No knowledge at all.

Regards,
Manni

jploski wrote on Sat Aug 25 14:33:12 MEST 2007:

Maybe the devguide document would be better without the introductory section
;-)

What I'd like to know is how long PerlCompletionProcessor.computeCompletionProposals
takes on your machine, using the ListUsers.pm example you sent me. You don't
need a profound knowledge of Java or Eclipse, just some time to play around
with them. Specifically, you'd need to import the plugin projects into workspace
as explained in the devguide, create a run configuration for the hosted
workbench (also described), then edit PerlCompletionProcessor.java to wrap
the method computeCompletionProposal's body in

long t1 = System.currentTimeMillis();
try { /* original method body comes here */ } finally
{
    long t2 = System.currentTimeMillis();
    System.err.println("it took " + (t2-t1) + " ms");
}

When you then trigger the completion by typing a '$' in an editor of the
hosted workbench then, the "it took n ms" message will appear in the Console
of the host workbench. On my machine it's around 500ms - not great performance,
for sure, but not a noticeable slowdown either.

mannih2001 wrote on Mon Aug 27 14:48:29 MEST 2007:

Hi Jan,

maybe you should leave the introduction in.

I tried what you suggested, but I didn't really achieve much. Sorry.

I did what you said and then tried to Run the project. Eclipse asked me
whether I'd like to ignore all the errors in epic (the Problems view reports
149 errors). I said "Yes, ignore them" and another Eclipse opened. I now
tried to load a Perl file into this new instance, but that didn't work.
All I got was a new tab that said "Epic Perl Editor" that didn't have any
contents, just the background color.

I was able to open files with other editors (.xml, .html), but Epic didn't
do anything.

No idea what I did wrong there, but seems that it wasn't that easy after
all.


Regards,
Manni

mannih2001 wrote on Mon Aug 27 15:58:41 MEST 2007:

OK. Disregard what I just posted.

I have a working debugging configuration now. What I didn't do was set the
JRE compatibility under Preferences to 1.4 (maybe your developer docs need
an extra sentence in this regard). 

Of course, I can now no longer replicate the problem. The times that I get
are slow (730, 690, and 700 msec, e.g.), but they aren't as drastic as the
ones I got earlier.

I'm stumped. But I guess that I will try to solve the problem in the old
fashioned Windows way: Reinstall Eclipse, reboot the system, and hope that
everything is well.


Thanks,
Manni

jploski wrote on Tue Aug 28 21:46:35 MEST 2007:

Thanks for looking into it. I committed a fix to CVS which practically eliminates
the 600-800 ms delay. There was some ancient code in this part of EPIC which
was still using regular expressions instead of relying on information computed
by the parser. The fix will become available in the next version of 'testing'.

mannih2001 wrote on Wed Aug 29 11:23:05 MEST 2007:

That sounds _very_ good. Thank you very much, Jan.

Manni

mannih2001 wrote on Sat Aug 25 10:44:05 MEST 2007:

Sorry, Jan, but I forgot to mention this in my previous posts: I am not
on Windows. All the tests I did where on machines running Ubuntu Feisty.


Regards,
Manni

mannih2001 wrote on Fri Aug 24 11:58:34 MEST 2007:

Hi and sorry for the silence.

I have a module that is unbearably slow with content assist. But I checked
it out in Eclipse 3.2 and it's the same there. I also checked in on another
system where I don't even have the corresponding project and found the same
thing. 

So although this is the completely wrong thread, I sent you a copy of the
module to your sf address. Simply trigger content-assist anywhere you like.



Regards,
Manni

wanda_b_anon wrote on Wed Aug 22 19:44:08 MEST 2007:

Platform: Windows XP service pack 2