Fw: Patch for File Scanning
Mike Skells
mike.skells at talk21.com
Sun Oct 23 11:41:21 PDT 2011
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/20111023/74efabd2/attachment.html
More information about the nio-dev
mailing list