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

Daniel Colascione
Tue Dec 11 01:41:00 GMT 2012

On 12/10/2012 5:36 PM, Ryan Johnson wrote:
> On 10/12/2012 7:58 PM, Daniel Colascione wrote:
>> We shouldn't need to read this file more than once. After the first run, the
>> system should be able to read emacs.exe from the standby list, not the disk.
> GCC bootstrap has *exactly* the same problem! Loading the binary from ./xgcc for
> each line of all those configure scripts takes longer than everything else put
> together; I could never figure out what was wrong, since the stage1 and stage2
> binaries are "only" about 90MB, and stripping (down to 25MB) didn't help at all.

Right: stripping wouldn't affect the number of pages demand-faulted from the image.

> I never reported it because I figured there was no way cygwin could make Windows
> decide what files to cache or not cache... but it would definitely be nice to
> see the problem go away.

This behavior is definitely surprising. It's sort of an evil-genie way to
provide cache coherency, I suppose.

>> Now, if we run emacs.exe from cmd, not bash, that's exactly what happens:
> <snip>
>> I came up with a simple test case that reproduces in cmd the behavior I see when
>> I run Emacs from bash. I've reproduced the program below. Here, I've compiled
>> a.exe with -DSLOW:
> I tried to test on my machine (w7 x64), but I can't get it to compile
> (GetFileSizeEx not found at link time):
> i686-pc-mingw32-gcc emacs-slow.c -DSLOW -lkernel32

I just used i686-w64-mingw32-gcc. I didn't even need -lkernel32.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Cygwin-developers mailing list