Bug 113110

Summary: Editor hint fixes sometimes take a while to remove the hint annotation
Product: java Reporter: _ wadechandler <wadechandler>
Component: HintsAssignee: Jan Lahoda <jlahoda>
Status: RESOLVED WONTFIX QA Contact: issues <issues.netbeans.org>
Priority: P4 CC: dalecooper82, gsporar, issues
Version: 6.xKeywords: PERFORMANCE
Target Milestone: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Report:

Description _ wadechandler 2007-08-17 17:36:34 UTC
This is in regard to a user issue and feedback from nbusers:

I was looking at this further, and it seems to me that part of the issue is that editor hints code fixes should
automatically update the errors listed for the document which they fix, unless they already are... I noticed though that
on my One laptop with Dual Core Intel, 2GB, OpenSuSE10.2, NB6 daily it is very fast, and when I tell it to add the
throws clause for a method it is almost instantaneously removed from the error bard...in a 2500+ line file...not that it
won't ever be slow. On my other system, Dual Core, 2GB, Windows XP Pro (different laptop vendor...Dell actually), NB5.5
the same process in a 1700+ line file it seems to take longer (2 or 3 seconds before the error annotation goes away). If
the annotations are not being removed before the parse (not sure on the threading and events here) then they could be
removed much faster. The parser will take a couple of seconds at best I think depending on the file size. 

When typing to fix an error it doesn't seem such an issue usually because of the way we register things as we type
though I have noticed that when I am typing at times the parser will not be run until I am finished typing all together,
so the changes seem to take longer to take, and it seems to be related to when background parsing takes place. There may
be some tricks the devs could use to make that better too, but certainly editor hint fixes could be given an ability to
hook into the error system and remove the specific fixed issue before parsing ever takes place...I think.

I didn't know where to actually put this...wasn't sure if it is MIME type specific or what. I figure if the editor
support provides the base API to remove a given annotation directly from an editor hint fix then it would be a good
start. I noticed there is the class org.netbeans.editor.Annotations which seemingly supports this...just not sure if it
is being used or if it is actually what would do this.
Comment 1 dalecooper82 2007-08-17 18:11:28 UTC
My use case was using the editor Anotations to add "throws SomeException" to method definition. There were 2 Exceptions
to  add and as Ctrl+Enter + Enter is fast to do, when I did Ctrl+Enter second time, the first (already "fixed")
Exception still showed in the list.

Thanks Wade for filing this and doing deeper analysis. 
Comment 2 Jan Lahoda 2007-08-20 17:57:39 UTC
Well, I am not sure against which version is the complaint meant: it says that NB6.0 removes the error almost instantly,
and that NB5.5 is slow in this regard - I do not think we can (now) do anything in NB5.5 for this.

What could be done (for NB6.0, if time permits), is that the Editor Hints API could, when a fix is implemented, remove
the corresponding error. Or all errors on the corresponding line - might be a bit trickier though, and also more
confusing. Might need some experiments.

I do not think that removing annotations before the parser starts is a good idea - the whole file might flicker (the
errors would be removed, the non-fixed ones would be put back, and so on).
Comment 3 Vitezslav Stejskal 2007-08-20 19:15:49 UTC
Ok, here is how I understand the report, please correct me if I am wrong. There is nothing we can do for 5.5.x, the
complaint is about hints annotations not being removed fast enough after a users chooses to apply the suggested fix. As
with any performance issue we need some serious numbers first in order to be able to start optimizing things. From what
jlahoda says I understand that there is no obvious problem in the code that we could easily fix.
Comment 4 _ wadechandler 2007-08-21 00:27:39 UTC
Other users have said the same about 6.0 in the lists as I have mentioned about 5.5. If the system isn't updating the
errors directly, and only relying on parsing, then it will inevitably have different times where lag will be greater as
it will be more dependent upon the CPU and other resources for performance. If you have an editor hint for a code fix it
shouldn't create error prone code, so if it removes the error it should not come back, and as a user can only make a
real action at a time, we really don't need to parse the document again on such a change. We can save some resources
[CPU, memory, and disk resources here]. If there is another hint or error for the same line then this one should still
be visible and shouldn't be removed, I imagine this built into the API, so I don't see why it has to cause flashing of
the error marker if both errors would have caused painting in the same region. Think of it as a stack of cards or layers
where you draw 3 red squares on top of each other. You pick one off and the color doesn't change. If each annotation
isn't asked to paint itself and another API or class does the painting based on whether an icon or some graphics should
be painted at point A or B or not then it should know whether there are other objects (in this case annotations) that
the given area or line will still be painted over and should update accordingly and not remove the drawing and graphics
if it still needs them.
Comment 5 Jan Lahoda 2007-08-21 18:09:18 UTC
As I said, we can remove the one annotation that corresponds to fix that has been implemented. The paragraph about
flickering was more about removing all error annotations from the whole file, which I though you were proposing (but
reading your comment again, I probably misunderstood this).
Comment 6 _ wadechandler 2007-08-21 20:40:13 UTC
Sorry if I wasn't more clear on my initial post. Looks like we're on the same page.
Comment 7 David Strupl 2009-03-31 15:59:58 UTC
Resolving all issues with milestone "future" as LATER. If you feel strongly that
it should be implemented please reopen and set the target milestone to "next".
Comment 8 Quality Engineering 2009-11-02 11:02:32 UTC
NetBeans.org Migration: changing resolution from LATER to WONTFIX
By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo