Community
Participate
Working Groups
Build Identifier: 20110615-0604 Hi, When opening a specific file, eclipse freezes every time for several seconds. I attached jstack output taken every second period while eclipse did not respond. Thanks, Yevgeny Reproducible: Always
Created attachment 205882 [details] 20111025.0954.53
Created attachment 205883 [details] 20111025.0954.55
Created attachment 205884 [details] 20111025.0954.56
Created attachment 205885 [details] 20111025.0954.57
Can you share the file for a reproducible test case? The thread dumps indicate that a TreeViewer.refresh() in the Outline view is taking a long time. In three cases the main thread is at org.eclipse.swt.internal.gtk.OS._gtk_tree_model_get_path() So, this could be a performance issue with SWT/GTK. Moving to Platform/SWT for comment.
Hi, Unfortunately I cannot share this file (our company code ...). I can say that this file has ~50K lines of "#define" statements. I am not sure I understand why code related to "Outline" view causes eclipse to freeze. In many cases when there is a big file, it takes time till "Outline" view is shown (meanwhile "Pending" is shown). But it does not freeze eclipse. BTW: As you mentioned, it is related to "Outline" view. If I close "Outline" view eclipse is not freezing. Thanks, Yevgeny
(In reply to comment #6) > Unfortunately I cannot share this file (our company code ...). I can say that > this file has ~50K lines of "#define" statements. By default opening a file with more than 5000 lines would enable "Scalability mode" to avoid such performance penalties. I assume the scalability mode preferences have been changed on your side. > I am not sure I understand why code related to "Outline" view causes eclipse to > freeze. In many cases when there is a big file, it takes time till "Outline" > view is shown (meanwhile "Pending" is shown). But it does not freeze eclipse. Populating the view with 50k items takes its time and this cannot be done in the background. I am moving this bug back to CDT.
(In reply to comment #7) > (In reply to comment #6) > > Unfortunately I cannot share this file (our company code ...). I can say that > > this file has ~50K lines of "#define" statements. > By default opening a file with more than 5000 lines would enable "Scalability > mode" to avoid such performance penalties. I assume the scalability mode > preferences have been changed on your side. You are correct, scalability mode was disabled. > > I am not sure I understand why code related to "Outline" view causes eclipse to > > freeze. In many cases when there is a big file, it takes time till "Outline" > > view is shown (meanwhile "Pending" is shown). But it does not freeze eclipse. > Populating the view with 50k items takes its time and this cannot be done in > the background. > I am moving this bug back to CDT. I still cannot understand why code in specific view causes eclipse to freeze (why cannot it be done in background ...). As far as I know, UI thread should not be blocking for several seconds. This is very problematic for users. There is no problem if outline will be built after several seconds, but it should not freeze eclipse. BTW: There are many files that have ~10K lines. It takes outline time to show the info (meanwhile "Pending" is shown), and it does not freeze eclipse.
(In reply to comment #8) > I still cannot understand why code in specific view causes eclipse to freeze > (why cannot it be done in background ...). As far as I know, UI thread should > not be blocking for several seconds. This is very problematic for users. The model is computed in the background, but populating the tree viewer must occur on the UI thread. We could use the TreeViewer in virtual mode where only items currently visible are realized, but that would require a major rework. > There is no problem if outline will be built after several seconds, but it > should not freeze eclipse. > > BTW: There are many files that have ~10K lines. It takes outline time to show > the info (meanwhile "Pending" is shown), and it does not freeze eclipse. It's the number of items to fill into the TreeViewer, not the file size in general. If you think the performance of the TreeViewer is not adequate, please file a bug with Platform/UI.
Hi, From what I understood from your reply: The problem is not caused as a result lines count the file, it is because outline view needs to populate ~50K items. I am not an eclipse developer so I cannot comment how it should be implemented. I do not think I need to open a new bug. This bug was opened for functionality problem, which needs to be addressed. It would be great if Platform/UI and CDT guys could decide who should handle this issue. BTW: Another thought, maybe you could add a new (additional) condition for scalability mode based on elements count and not lines number. Let me know, if you want me to open a feature request for this. Thanks a lot, Yevgeny
(In reply to comment #10) > BTW: Another thought, maybe you could add a new (additional) condition for > scalability mode based on elements count and not lines number. Let me know, if > you want me to open a feature request for this. This would require parsing the file, but that itself might incur a performance or memory issue. Scalability mode must be enabled based on a simple heuristic.
I did some tests on Windows and adding 50,000 items to a tree without JFace takes over 60 seconds. Either SWT could try to optimize this or CDT can change their code to use a virtual tree. A DeferredTreeContentManager might help but I'm not sure.
> Either SWT could try to optimize this or CDT can change > their code to use a virtual tree. CDT should be using a virtual tree.
