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

Ryan Johnson
Wed Dec 12 18:42:00 GMT 2012

On 12/12/2012 12:11 PM, Christopher Faylor wrote:
> On Wed, Dec 12, 2012 at 12:06:08PM -0500, Ryan Johnson wrote:
>> It's painfully reproducible. It takes nearly two hours for a gcc
>> bootstrap compiler to configure the various bits of the next stage. It's
>> the same for emacs unexec (as OP reported).
> I'd like to see a small controlled test case which demonstrates the
> problem.  If the claims here are all true then it should be very easy to
> demonstrate without resorting to bootstrapping the compiler.

# fast: ~60ms
cp --sparse=never $(which emacs-nox) foo
for i in $(seq 10); do time ./foo -Q --batch --eval '(kill-emacs)'; done

# slow: ~800ms
cp --sparse=always $(which emacs-nox) foo
for i in $(seq 10); do time ./foo -Q --batch --eval '(kill-emacs)'; done

# even slower: ~3.5s (size on disk doubled)
cp --sparse=never $(which emacs-nox) foo
for i in $(seq 10); do time ./foo -Q --batch --eval '(kill-emacs)'; done

# fast again: ~60ms
rm foo
cp --sparse=never $(which emacs-nox) foo
for i in $(seq 10); do time ./foo -Q --batch --eval '(kill-emacs)'; done

> And, given my comment about setup.exe, I suspect that this isn't going
> to be as alarming an issue for the normal Cygwin user as it is for
> people who, e.g., rebuild their own compilers.  I'll bet setup.exe
> doesn't know anything about sparse files so all of the executables
> and dll should not be sparse.
> Can anyone confirm or deny that?
Confirmed. The sparse flag is lost during normal copies because cygwin 
has to ask for it specifically during an lseek or ftruncate past end. 
Clobbering an existing file does not clear the flag, however.

Further, gcc doesn't seem to produce executables with holes in them, it 
just writes some of the sections out of order. So even if you did make 
setup.exe sparse file aware, it still shouldn't matter except for files 
like emacs that do horrible things to themselves (cue post-install script).


More information about the Cygwin-developers mailing list