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] |
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] |