@Stefan, can you open a bug report for the O(n^2) performance in creating N tabs? This sounds definitely wrong. If you already have some tracing data why this happens, please attach it to the bug (or even better upload a fix for this behavior). Maybe more issues like Bug 467499, or maybe also solved with this bug.
I personally switch on auto-close of editors whenever I notice a UI delay with my >99+ editors but I agree to the general discussion that setting auto close as default might be distracting for the user.
Maybe we could bring up a small info popup the first time we hit more then 99 editors and inform the user about the auto-close performance advantage and allow to activate the setting via this popup?
Best regards, Lars
Am 15.03.2016 1:32 vorm. schrieb "Stefan Xenos" <
sxenos@xxxxxxxxx>:
> the number of apparently open tabs can grow to hundreds with little to no performance penalty as there are no SWT controls or listeners.
Actually, some of the performance problems occur even with just tabs -- for example, incrementing the number of tabs requires instantiating a CTabItem, and creating n CTabItems takes O(n^2) time. It has a low constant, but if you create enough tabs (even without realized editors), it gets very slow.
- Stefan
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev