Bug 361891

Comment 1 Yevgeny Shifrin 2011-10-25 03:59:49 EDT

Created attachment 205882 [details]
20111025.0954.53

Comment 2 Yevgeny Shifrin 2011-10-25 04:00:59 EDT

Created attachment 205883 [details]
20111025.0954.55

Comment 3 Yevgeny Shifrin 2011-10-25 04:01:23 EDT

Created attachment 205884 [details]
20111025.0954.56

Comment 4 Yevgeny Shifrin 2011-10-25 04:01:44 EDT

Created attachment 205885 [details]
20111025.0954.57

Comment 5 Anton Leherbauer 2011-10-28 08:30:36 EDT

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.

Comment 6 Yevgeny Shifrin 2011-10-30 03:54:56 EDT

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

Comment 7 Anton Leherbauer 2011-11-02 05:48:10 EDT

(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.

Comment 8 Yevgeny Shifrin 2011-11-03 04:21:33 EDT

(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.

Comment 9 Anton Leherbauer 2011-11-03 04:45:05 EDT

(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.

Comment 10 Yevgeny Shifrin 2011-11-03 07:43:19 EDT

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

Comment 11 Anton Leherbauer 2011-11-03 08:33:04 EDT

(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.

Comment 12 Remy Suen 2011-11-18 13:46:39 EST

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.

Comment 13 Felipe Heidrich 2011-11-21 10:56:36 EST

> 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.