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.
We have all module layers covered by one MultiFileSystem that uses a linear searching for operations e.g. getAttribute(), findResource(), etc. We should provide a better, more specialized, implementation for this case. There are two proposals - add a new addXML() method to XMLFileSystem, or merge XML documents to one and then create new XMLFileSystem. We should gain performance boost on startup - 10%. We could lose CPU ticks in an "uninstall module" action, as we will need to rebuild this filesystem.
Or, a special subclass of MultiFileSystem (for read-only delegates only) that would precalculate all attributes and file structure. I.e.: keep a cache of known file structure, and when a new delegate is added, merge its contents into this cache. If a delegate is deleted, recalculate the cache. This approach would remove anything specific to XMLFileSystem and might be easier to understand.
Is not the trouble with the way how MultiFileSystem handles attributes? I know that Jesse enhanced it to allow to store attributes for file from any layer (even the layer is read-only). As far as I know the algorithm scans all(?) layers to find if a file object has attribute or not. I think that the real bottleneck is this algorithm. Would it be an improvement to just check all delegates of a file object plus value on the first (read-write) filesystem layer?
The problem with addXML is that it does not logically fit into the public interface, it is useful just for this special case. The possible solution would be to create own URLHandler, URLConnection that would use SequenceInputStream and merge all layers from all modules together. Because the XMLFileSystem does not use validating parser, it could work.
That`s true that addXML does not logically fit into the public interface. We could bend it a little: setXmlUrl and getXmlUrl could be considered as getter and setter for primary URL and add methods setSecondaryXmlUrl and getSecondaryXmlUrl with obvious meaning. SystemName would reflect primary URL. Implementation would be really easy. It is also not bad idea to merge all documents using SequenceInputStream.
Take care that in the case of SequenceInputStream that all files must: * use same encoding * be free of prologs <?xml * an artifial file adding prolog and root element must be introduced * an artifial file closing root element must be introduced Not sure if it is not too complex. May be, a solution introducing master document referencing all others would be easier (however it does not eliminate performace problem with creating Readers for every external entity).
I have to add something here to assign this bug :-(
Version: 'Dev' -> 3.2
Let's leave it for 3.3
Target milestone -> 3.3
Already implemented - XMLFileSystem.setXmlUrls() in v1.32
something
Resolved for 3.4.x or earlier, no new info since then -> closing.