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 62048 - ModuleList.findBinaryNBMFiles is slow
Summary: ModuleList.findBinaryNBMFiles is slow
Status: RESOLVED WONTFIX
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 5.x
Hardware: All All
: P4 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: PERFORMANCE
: 60973 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-10 14:29 UTC by _ rkubacki
Modified: 2007-10-24 22:48 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
SAX patch which is strangly slower then the current DOM implementation (3.31 KB, patch)
2005-11-24 13:12 UTC, Martin Krauskopf
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2005-08-10 14:29:03 UTC
This method is called when I select folder of my NBM project to find all files
belonging to some NBM that is part of platform.

It parses update tracking file with DOM and then traverses its elements to build
the results. It should be faster to do it SAX - the structure of document is
very simple and we can avoid a lot of garbage that is created.
Comment 1 _ rkubacki 2005-08-10 14:50:45 UTC
Creating of files from strings is reasonably fast except modules like bundled
Tomcat that contains huge number of file. BTW: why we need these information? Or
why we need them while project is opening?
Comment 2 Jesse Glick 2005-08-10 16:57:43 UTC
I know SAX would be faster.

The info is probably not needed during project opening as such, but it may be
needed later when the project is being edited, mainly for code completion.

Could be deferred/optimized in various ways. No time to work on it yet.
Comment 3 _ rkubacki 2005-09-02 21:04:35 UTC
*** Issue 60973 has been marked as a duplicate of this issue. ***
Comment 4 Martin Krauskopf 2005-11-24 09:04:25 UTC
I can help at least with SAX utilization phase.
Comment 5 Martin Krauskopf 2005-11-24 13:12:26 UTC
Created attachment 27240 [details]
SAX patch which is strangly slower then the current DOM implementation
Comment 6 Martin Krauskopf 2005-11-24 13:12:51 UTC
Attaching patch we were examining here. To try it run e.g.
ModuleListTest.testExternalEntries().
Comment 7 Martin Krauskopf 2005-11-29 15:08:30 UTC
Any news Radime? Should we switch to good-manner behaviour (SAX) or stay with
currently (surprisingly) fastest implementation (DOM).
Comment 8 Martin Krauskopf 2005-12-12 12:35:14 UTC
Three weeks without feedback. Let's stay with DOM when is is even faster then SAX. 

Not closing yet since Jesse might have some ideas ("Could be deferred/optimized
in various ways.")
But main Radim's point was considered --> P4
Comment 9 Jesse Glick 2007-10-24 22:48:37 UTC
When the optimization mentioned by issue #114155 is active, this method is not called (unless you e.g. use the Add
Module Dependency dialog, when dependent modules need to be scanned in more detail anyway).