Fw: Patch for File Scanning

[Mike Skells]

Hi Alan,
After running it a couple of dozen times, the timings seem to be about 20-30 ms slower but the difference between successive runs (the error tolerance) is 5-10 ms, so it seems to have captured the significant majority of the change.


WRT to the changes for WindowsPathWithAttributes is it not worth having some mechanism to avoid Path.getParent() causing additional object creation, and potential loss of the file attributes, as the information is available at the time of construction of the object? This could be done as a WeakRefernce to avoid memory usage utilisation

The change that I had in WindowsPathWithAttributes was originally to speed up the getFileName (otherwise the getFilename in WindowPath scans for '\\' in the file name to determine the start of the file name etc )
I presume that this is the cause of the different timings, but I cannot verify easily as my profier refuses to project code and instruments the VM code ....

Regards


Mike



>________________________________
>From: Mike Skells <mike.skells at talk21.com>
>To: Alan Bateman <Alan.Bateman at oracle.com>
>Cc: nio-dev <nio-dev at openjdk.java.net>
>Sent: Sunday, 23 October 2011, 19:41
>Subject: Re: Fw: Patch for File Scanning
>
>
>Hi Alan,
>Will do,
>cant remember if the parent path was useful in itself but it seemed to me that the reference was for free (although a Weakreference may be a better choice) and avoid the cost of a path creation/parse - I will check
>
>
>from memory I think that the biggest simple gains were the stringbuffer removal (as you mentioned)
>
>
>I dont have code access for a few days so it will be towards the end of week before I get back to you
>
>
>Regards
>
>
>Mike
>
>
>
>>________________________________
>>From: Alan Bateman <Alan.Bateman at oracle.com>
>>To: mike.skells at talk21.com
>>Cc: nio-dev <nio-dev at openjdk.java.net>
>>Sent: Saturday, 22 October 2011, 18:05
>>Subject: Re: Fw: Patch for File Scanning
>>
>>On 09/10/2011 23:07, mike.skells at talk21.com wrote:
>>> Hi All,
>>> I have a few optimisations that I have found in nio2 Path Scanning.
>>> I found these during the scanning phase of the jar improvements that I
>>> have been working on
>>> 
>>> The changes only really affect the first few runs thorough the code, and
>>> after
 the scan of the first 20K files there is not much difference,
>>> however this does mean a significant improvement for small utility apps
>>> (e.g. jar). Most of the improvement were if the path scanning (removing
>>> as string+=string that could be optimised), and changes to the
>>> WindowsPathWithAttributes
>>
>>I went through your patch and put a webrev (essentially browsable diffs) here:
>>http://cr.openjdk.java.net/~alanb/7103889/webrev.01/
>>
>>As we discussed, there isn't a typo in the javadoc so we'll ignore that. On Files.ACCEPT_ALL then I think it's best not to add a static field to avoid loading Filter until it is needed.
>>
>>In WindowsPathParser the changes avoid concatenating "\" then the root component already is of the format C:\. That seems reasonable to me although the changes need to handle input such as C: as otherwise this code
 will fail with IndexOutOfBoundException.
>>
>>I'm not sure about the changes to WindowsPathWithAttributes. The original intention was to allow for very temporary caching of the attributes during the directory iteration and we don't want the Path instance to keep the reference forever. Also the additional reference to the parent introduced by the changes is a concern.
>>
>>The changes to WindowsDirectoryStream make sense to me as it means the entries are prefix + name rather than dir + "\" + name. Also it avoids constructing a WindowsFileAttribtues for the links to the current directory and the parent.
>>
>>I've create a second webrev. This leaves out the changes to WindowsPathWithAttributes and does a few clean-ups:
>>http://cr.openjdk.java.net/~alanb/7103889/webrev.02/
>>
>>I'd be interested if you could repeat you tests to see how they compare in your
 environment.
>>
>>-Alan.
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20111027/57fc8d21/attachment.html