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

Corinna Vinschen
Wed Dec 12 15:56:00 GMT 2012

On Dec 12 10:39, Ryan Johnson wrote:
> On 12/12/2012 9:04 AM, Eric Blake wrote:
> >In other words, I'm proposing that we delete nothing from cygwin1.dll,
> >and instead fix the problem apps (gcc, emacs unexec) that actually
> >create executables, so that the files they create are non-sparse because
> >we have proven that they should not be sparse for performance reasons.
> >Meanwhile, all non-executable files (such as virtual machine disk
> >images, which are typically much bigger than executables, and where
> >being sparse really does matter) do not have to jump through extra hoops
> >of using ftruncate() when plain lseek() would do to keep them sparse.
> Does gcc/ld/whatever know the final file size before the first write?
> You have to posix_fallocate the entire file before any write that
> might create a hole, because the sparse flag poisons the loader, and
> persists even if all gaps are later filled. For example, if I invoke
> the following commands:
> cp --sparse=always $(which emacs-nox) sparse
> cp --sparse=never $(which emacs-nox) dense
> for f in sparse dense; do echo $f; time ./$f -Q --batch --eval
> '(kill-emacs)'; done
> cp --sparse=never dense sparse
> for f in sparse dense; do echo $f; time ./$f -Q --batch --eval
> '(kill-emacs)'; done
> du dense sparse
> The relevant output is:
> >sparse
> >real    0m1.791s
> >
> >dense
> >real    0m0.606s
> >
> >sparse
> >real    0m3.158s
> >
> >dense
> >real    0m0.081s
> >
> >16728   dense
> >16768   sparse
> Given that we're talking about cygwin-specific patches for emacs and
> binutils anyway, would it be better to add a cygwin-specific fcntl
> call that clears the file's sparse flag?

This is not supported in pre-Vista OSes.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

More information about the Cygwin-developers mailing list