| [cdt-core-dev] 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