Performance optimization in av::fixup - use buffered IO, not mapped file

Ryan Johnson ryan.johnson@cs.utoronto.ca
Thu Dec 27 22:53:00 GMT 2012


On 14/12/2012 4:18 AM, Corinna Vinschen wrote:
> On Dec 13 19:53, Corinna Vinschen wrote:
>> On Dec 13 10:32, Eric Blake wrote:
>>> On 12/13/2012 07:30 AM, Corinna Vinschen wrote:
>>>> Below is my cut on the issue.  It introduces a "sparse" mount option and
>>>> sparsifies a file only if this mount option is set.  I also slightly
>>>> improved the code in fhandler_base::write and ftruncate so that it will
>>>> not try to set the sparse flag on already sparse files.
>>>>
>>>> The code compiles, so it's basically correct.  It's just not tested. ;)
>>> Also untested (so far) on my end, but I can agree to this - anyone that
>>> _wants_ sparse files (such as for virtual disk image) will have to
>>> enable that mount point option for the directory of those files in
>>> question, but no one else is forced to use them.  As sparse files are
>>> _supposed_ to be an optimization, not being sparse is not a loss in
>>> functionality, just in potential optimizations; but if Windows is not
>>> taking advantage of optimizations even when a file IS sparse, then that
>>> argues that we aren't losing much.
>>>
>>> It should not be too hard for me to rig the coreutils testsuite to
>>> ensure that its tests of sparse operations are done on a mount
>>> explicitly set up to allow sparse files.
>> Yup, just add a temporary user mount point.
> I applied my patch with a single fix.  The logic for adding the "sparse"\
> option string to mnt_opts was upside down.
I just finished building gcc-4.7 using the latest cygwin1 snapshot, and 
performance is vastly, drastically improved. Stages 2 and 3 went as fast 
as Stage 1, and the disk light only flickered occasionally instead of 
staying pegged like it used to.

Thanks for finding and fixing this!

Ryan



More information about the Cygwin-developers mailing list