Community
Participate
Working Groups
First, this is probably not a "it does not work as expected" kind of bug, it is a "it does take just forever" bug. While saving, eclipse freezes while it tries (my guess) to expand many macros. The source file happens to contain some macros, which expand to 10000 (or even 100000 or 1000000) distinct classes. It looks like CDT is enumerating those classes, and this just takes literally forever. I assume than one day eclipse would start to react to user interaction again, but even for 10000, I did never wait that long. To make this clear, I don't think that any tool has to handle 10000000 classes in a reasonable fashion. But I consider it to be bug if an editor just blocks when it saves a source file. It should be possible to save any legal source file, even one with such content. It would be a perfect solution if the listing of all the object would happen in the background and be interruptible. It would be good enough this case would not list all the classes, but I see that arbitrary limits should be avoided. Anyway, to edit a file like the one below, I have to use another editor like notepad for now ;-) Daniel To reproduce, copy paste the code below into a new C++ source file, save it. Note: The line "#define L() L6(_)" can be changed to "#define L() L3(_)", then eclipse freezes for some seconds, but apart from this it remains responsive. // test file to generate huge apps, generates tons of classes. // be careful, when setting the L() to larger values, the number of classes grow exponentially and many things start taking forever (scanning for Outline view,...) #include <stdio.h> int main() { while(1) { printf("Hello World\n\r"); fflush(stdout); } return 0; } void DidCall(const char* c) { printf(c); } #pragma optimization_level 0 #pragma dont_inline on #define REF(c) DidCall(#c) #define L0(A) class class##A { public: class##A() { REF(class##A); fun(); } int m; void fun(void) {m++;}} DummyInstanceclass##A; #define L1(A) L0(A ## 0) L0(A ## 1) L0(A ## 2) L0(A ## 3) L0(A ## 4) L0(A ## 5) L0(A ## 6) L0(A ## 7) L0(A ## 8) L0(A ## 9) #define L2(A) L1(A ## 0) L1(A ## 1) L1(A ## 2) L1(A ## 3) L1(A ## 4) L1(A ## 5) L1(A ## 6) L1(A ## 7) L1(A ## 8) L1(A ## 9) #define L3(A) L2(A ## 0) L2(A ## 1) L2(A ## 2) L2(A ## 3) L2(A ## 4) L2(A ## 5) L2(A ## 6) L2(A ## 7) L2(A ## 8) L2(A ## 9) #define L4(A) L3(A ## 0) L3(A ## 1) L3(A ## 2) L3(A ## 3) L3(A ## 4) L3(A ## 5) L3(A ## 6) L3(A ## 7) L3(A ## 8) L3(A ## 9) #define L5(A) L4(A ## 0) L4(A ## 1) L4(A ## 2) L4(A ## 3) L4(A ## 4) L4(A ## 5) L4(A ## 6) L4(A ## 7) L4(A ## 8) L4(A ## 9) #define L6(A) L5(A ## 0) L5(A ## 1) L5(A ## 2) L5(A ## 3) L5(A ## 4) L5(A ## 5) L5(A ## 6) L5(A ## 7) L5(A ## 8) L5(A ## 9) #define L() L6(_) L()
Created attachment 61147 [details] source file to reproduce issue (set to 10000 classes) try: #define L() L6(_) to get 1000000 classes, or create a L7,L8 to get more ;-)
If you don't have the heap size set pretty high, just putting this into the editor causes the reconciler to blow up with an OutOfMemoryException. This is without saving the file. In general the problem here is that when you make changes, the parse is kicked off on the working copy, and a CModel is created from it. This model is then compared to the existing model prior to the edit to generate the ICElementDelta. If you have a lot of code (e.g. your 1 million classes), this is going to take a lot of time and memory and there isn't much way around that. It is possible that we can further optimize the memory usage and the algorithmic complexity of these operations, but regardless the expectation is going to be that parsing 1 million classes and putting them in the outline view is going to take a long time. I would suggest that for files like this you close the outline view.
