This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.




Attachment: signature.asc
Description: OpenPGP digital signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]