This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 161336 - MimeLookup occupies 100% for minutes after intalling a module
Summary: MimeLookup occupies 100% for minutes after intalling a module
Status: RESOLVED DUPLICATE of bug 161201
Alias: None
Product: editor
Classification: Unclassified
Component: Settings (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Vitezslav Stejskal
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2009-03-27 11:43 UTC by Jaroslav Tulach
Modified: 2009-04-06 13:21 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
The profiler result, expand thread named "ModuleList.Listener" (65.18 KB, application/octet-stream)
2009-03-27 11:45 UTC, Jaroslav Tulach
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2009-03-27 11:43:00 UTC
I downloaded Ant viewer NBM:
http://www.ssw.uni-linz.ac.at/Teaching/Lectures/SpezialLVA/TulachWielenga/projects/index.html#ant
and when I installed it as "downloaded" the CPU raised to 100% and stayed there for minutes.

I took "Profile Me!" snapshot and it shows a lot calls to mimelookup's rebuild() method. I am afraid there is some 
ineffectivity or "endless" loop. Can that be eliminated a bit?
Comment 1 Jaroslav Tulach 2009-03-27 11:45:24 UTC
Created attachment 78965 [details]
The profiler result, expand thread named "ModuleList.Listener"
Comment 2 Vitezslav Stejskal 2009-03-31 10:04:45 UTC
Well, most likely events arrived from System FileSystem and caused MimeLookup recalculation. This is likely to require
some investigation.
Comment 3 Jaroslav Tulach 2009-03-31 11:22:28 UTC
Indeed some changes arrived after enabling a module. But one recalculation would be enough.
Comment 4 Vitezslav Stejskal 2009-03-31 15:13:55 UTC
"Indeed some changes arrived after enabling a module. But one recalculation would be enough." - Perhaps more than just
one change event arrived... Anyway, this leads nowhere. It would be useful to know, for example, that a batch of events
is being fired at the end of AtomicAction and do just one recalculation for the whole batch. But that I think is not
currently possible. And so the only other way I am aware of is a 'sliding task' (ie. rescheduling a task with some delay
in RequestProcessor every time a change event arrives), which will make MimeLookup less deterministic, may affect tests
etc... Or is there a page in the bible I should look at? :-)
Comment 5 Vitezslav Stejskal 2009-03-31 16:45:27 UTC
CompoundFolderChildren.rebuild() seems to be called too much. Jesse could you please help with this? If not, feel free
to reassign back to me. Thanks
Comment 6 Jesse Glick 2009-03-31 18:17:11 UTC
I'm afraid I don't know of any easy way to make it better. Asynch change firing is definitely undesirable. Perhaps you
can fire some kind of "something changed" event immediately, and if other code asks for the actual new value, then you
recalculate. Or perhaps rebuild can be interruptible, so if a new event comes in, cancel the previous rebuild task and
restart it.
Comment 7 Vitezslav Stejskal 2009-04-06 13:21:34 UTC

*** This issue has been marked as a duplicate of 161201 ***