Re: [cdt-core-dev] Bad scalability news

[Chris Songer <songer@xxxxxxxxxxxxx>]

Clever test!

It certainly explains some inexplicable behavior we have been seeing in 
testing. We just did some chatting about it internally. It "should" be easy 
to diagnose. Do what you are doing but call gc(), dump all the objects 
allocated in the jvm, open editor, close editor, call gc() dump all the 
objects allocated in the jvm. That should point the mighty finger of blame 
pretty clearly.

Unfortunately no one here yet knows how to dump all the objects allocated 
in the jvm. Hprof is lovely, but to nail this we really don't want to track 
everything for all time, we just want to dump twice and see what's new. Any 
pointers on how to do that?

Thanks!
-Chris

At 09:47 AM 5/12/2004 -0400, Thomas Fletcher wrote:
> Folks,
>
>   I've been running some tests to reproduce some user scenarios we
> have been looking at (with CDT 1.2.* thus far) and have some not so
> great news.
>
> Running the attached code, which is an object contribution to an IFile
> which simply spins in a loop opening the editor for that file and then
> closing it I've found the following:
>
> Running against the .project file (or any other text file)
> -> 260 000+ iterations and still going strong
>
> Running against a simple .c file:
> -> 1 047 iterations then an out of memory error on the editor
>
> Running against a simple .c file but with System.gc() after
> every interation:
> -> 1 050 iterations then an out of memory error on the editor
>
> Running against a simple .c file which has no header
> files #included:
> -> 1 076 iterations then an out of memory error on the editor
>
> Running against a simple .c file but with the outline
> view closed
> -> 1 099 iterations then an out of memory error on the editor
>
> These tests were run on a Windows XP system (512M RAM) in a
> runtime workbench using CDT 1.2.1 and Eclipse 2.1.2.  The workbench
> was using the "stock" arguments for eclipse.  Changing the
> memory settings (or the contents of the file) just ended up
> delaying (or speeding up) the crash.
>
> I'll be filing a bugzilla entry to track this, but thought that
> others might be interested in the results and have comments on
> the validity of the tests.