| Summary: | [Markers] QuickFixPropertyTester could check for marker's validity | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Prakash Rangaraj <prakash> | ||||
| Component: | IDE | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | trivial | ||||||
| Priority: | P3 | CC: | bokowski, daniel_megert, grprakash, jamesblackburn+eclipse, Lars.Vogel, remy.suen | ||||
| Version: | 3.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
|
Description
Prakash Rangaraj
Created attachment 196075 [details] Patch v01 This comes in as an interesting case from Bug# 345608. When too many markers are deleted from the Problems View, it takes some time. Marker deletion is faster, but the UI takes a while to refresh them (and it is done in a different job). Meanwhile if the user switches to a different window and comes back, then the QuickFixPropertyTester is invoked to check for *each* of the selected markers. Since those markers are no longer valid, exceptions are thrown in MarkerQuery.performQuery(). For the aforementioned bug, thousands of exceptions were thrown. We could add this simple optimization to check whether a marker is valid or not and then proceed. Boris/Dani,
Is this a good candidate for 3.7 RC2?
> Is this a good candidate for 3.7 RC2?
At this point I would vote -1 for RC2 for the following reasons:
1. The call to IMarker.exists() is not cheap: it does a (path) lookup in
the workspace's element tree. This means while improving the performance of
the delete case we might destroy the performance for the normal case where
many elements are selected and the tester gets invoked.
2. It is not a regression (like that for at least more than 3 years).
3. AFAIK we do not have performance tests that would allow us to verify that the
impact mentioned in 1. is not an issues and that we indeed improve the
'delete' case.
Having said that, I think the fix is a good idea but a bit too late. During 3.8/4.2 we should add performance tests and see how the fix behaves. If it is doing well we could backport it to 3.7.1.
(In reply to comment #3) OK (In reply to Prakash Rangaraj from comment #1) > Created attachment 196075 [details] > Patch v01 Sorry, that your patch was overseen. Are you still around? If yes, could you convert the patch into a Gerrit review? Hi Lars,
I'm in a different universe. To start with, first I need to install Java and learn Gerrit :-)
But I'll try to have this as a reason to install everything and give it a shot. Thanks!
PS: I also lost my other email id to which the bug is been assigned, so have to stick with this gmail id.
(In reply to Prakash G.R. from comment #6) > I'm in a different universe. To start with, first I need to install Java > and learn Gerrit :-) I hope the following tutorial will help you: http://www.vogella.com/tutorials/EclipsePlatformDevelopment/article.html#eclipsegerritcontribution This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |