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

Bug 337370

Summary: Optimization for BaseAdaptor.listEntryPaths
Product: [Eclipse Project] Equinox Reporter: John Ross <jwross>
Component: FrameworkAssignee: John Ross <jwross>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: tjwatson
Version: unspecified   
Target Milestone: 3.7 M6   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
Use BundleFile.getEntryPath for special case tjwatson: iplog+

Description John Ross CLA 2011-02-16 16:45:02 EST 
Build Identifier: 

The BaseAdaptor.listEntryPaths method should be optimized for the case where no wildcards are specified (i.e. a specific file is being searched for). This is anticipated to be a common case. This method serves the Bundle and BundleWiring findEntries methods.

Reproducible: Always
Comment 1 John Ross CLA 2011-02-16 17:00:26 EST 
The performance test consisted of the following.

- A single bundle with 33 files within the OSGI-OPT directory for a total size of 25.5 MB.

- A call to findEntries with "OSGI-OPT" as the path and a specific file name as the filePattern.

- Times are based on a 1000 iteration loop.

Before Patch

Average time across 10 runs was 701.5 ms.

After Patch

Average time across 10 runs was 75.1 ms.

The patch has no discernable negative effects on search times with wildcards.
Comment 2 John Ross CLA 2011-02-16 17:04:07 EST 
Created attachment 189138 [details]
Use BundleFile.getEntryPath for special case

This patch looks to see if there are any wildcards specified as part of the filePattern and whether or not recursion was requested. If not, a call to BundleFile.getEntryPath is used instead.
Comment 3 Thomas Watson CLA 2011-02-17 09:54:19 EST 
Patch looks good and I released it.

I think there is room for improvement when recursing in org.eclipse.osgi.baseadaptor.BaseAdaptor.listEntryPaths(BundleFile, String, Filter, Hashtable<String, String>, int, List<String>).  We really should avoid calling org.eclipse.osgi.baseadaptor.bundlefile.BundleFile.getEntryPaths(String) over and over each time we recurse.  It should be possible to build the list of files that match a given path, filter and if we should recurse into sub folders with one pass over the results of BundleFile.getEntryPaths(String)

John, could you open another bug to investigate this possible optimization?
Comment 4 Thomas Watson CLA 2011-02-17 15:38:04 EST 
(In reply to comment #3)
> Patch looks good and I released it.
> 
> I think there is room for improvement when recursing in
> org.eclipse.osgi.baseadaptor.BaseAdaptor.listEntryPaths(BundleFile, String,
> Filter, Hashtable<String, String>, int, List<String>).  We really should avoid
> calling
> org.eclipse.osgi.baseadaptor.bundlefile.BundleFile.getEntryPaths(String) over
> and over each time we recurse.  It should be possible to build the list of
> files that match a given path, filter and if we should recurse into sub folders
> with one pass over the results of BundleFile.getEntryPaths(String)
> 
> John, could you open another bug to investigate this possible optimization?

We discussed this more and decided that we should not optimize the recursive case for now.  It would require an API addition to BundleFile which needs careful consideration because of framework extensions that can wrap bundle file objects.  These wrapper bundle files would not be calling the new API on BundleFile so they would not take advantage of any optimizations we would do for ZipBundleFile.
Comment 5 Thomas Watson CLA 2011-02-18 10:54:54 EST 
Note that the patch released with this bugs caused bug 337569.