On 01/05/2010 11:22 AM, David M. Lloyd wrote:
On 01/05/2010 11:18 AM, Bill Burke wrote:
>
>
> David M. Lloyd wrote:
>> On 01/05/2010 10:40 AM, Bill Burke wrote:
>>>
>>> Ales Justin wrote:
>>>> Perhaps this can be solved by custom (+ temp) deployer,
>>>> which would create capabilities from those exports,
>>>> but would just say import-all for imports.
>>>>
>>> No shit shirlock...Especially when thats what is being done now.
>>>
>>> Again, optimizing this algorithm doesn't matter if jars/directories are
>>> being browsed.
>>
>> What do you mean by "browsed"? If you're going to access any file
in a
>> JAR, you need to scan the (unordered) ZIP directory anyway. Better to do
>> it one time and cache it so files can be looked up on an O(1) basis. And
>> once you've done that, why not use that data for other purposes?
>>
>
> A simple test of using ZipInputStream vs. URLClassLoader to find a
> resource within jacorb.jar.
>
> ZipInputStream: 256ms.
> URLClassLoader: 5ms.
>
> URLClasLoader is obviously using some other mechanism to find things.
Uh yeah using ZIS is a really bad idea for reasons covered several
months ago. URLClassLoader is opening a ZipFile.
To spell it out, a ZIP file is divided up into many sections. The
directory is at the end of the zip file. Using ZIS iterates the sections
corresponding to files - which is NOT guaranteed to work right - and thus
passes over the entire file in the process. Using ZipFile simply reads the
directory which is at the END of the zip file and is stored in a much more
compact fashion - less I/O, more speed.
Anyway this has all been covered, benchmarked, and fixed by VFS3.
- DML