Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346372

Summary: [Markers] QuickFixPropertyTester could check for marker's validity
Product: [Eclipse Project] Platform Reporter: Prakash Rangaraj <prakash>
Component: IDEAssignee: 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 Flags
Patch v01 none

Description Prakash Rangaraj CLA 2011-05-19 03:08:23 EDT
When asked, the QuickFixPropertyTester goes to markerHelpRegistry and checks whether it has any resolutions. As a small optimization it could check for whether the marker is valid or not.

This is a follow up from Bug# 345608
Comment 1 Prakash Rangaraj CLA 2011-05-19 03:19:04 EDT
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.
Comment 2 Prakash Rangaraj CLA 2011-05-19 03:22:33 EDT
Boris/Dani,

     Is this a good candidate for 3.7 RC2?
Comment 3 Dani Megert CLA 2011-05-19 04:49:24 EDT
> 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.
Comment 4 Prakash Rangaraj CLA 2011-05-19 06:47:37 EDT
(In reply to comment #3)

   OK
Comment 5 Lars Vogel CLA 2014-07-03 16:01:28 EDT
(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?
Comment 6 Prakash G.R. CLA 2014-07-07 02:43:03 EDT
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.
Comment 7 Lars Vogel CLA 2014-07-07 02:53:25 EDT
(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
Comment 8 Eclipse Genie CLA 2019-10-25 19:03:28 EDT
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.