| [cdt-ui-dev] Bad scalability news |
This probably should have been posted to the UI list rather than the core-dev list. The PR has been created: 61965 Thanks, Thomas >-----Original Message----- >From: Thomas Fletcher >Sent: May 12, 2004 9:47 AM >To: 'cdt-core-dev@xxxxxxxxxxx' >Subject: Bad scalability news > > >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. >
Attachment:
EditorCycleActionDelegate.java
Description: Binary data