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 6:32 PM, Ryan Johnson wrote:
> On 10/12/2012 8:41 PM, Daniel Colascione wrote:
>> On 12/10/2012 5:36 PM, Ryan Johnson wrote:
>>> 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.
> OK, that compiles, but I can't repro:
> 
> $ time emacs-nox --batch -Q --eval '(kill-emacs)'
> 
> real    0m0.057s
> user    0m0.031s
> sys     0m0.015s
> 
> $ time emacs-nox --batch -Q --eval '(kill-emacs)'
> 
> real    0m0.058s
> user    0m0.031s
> sys     0m0.015s
> 
> $ time ./emacs-slow $(cygpath -wa $(which emacs-nox.exe))
> Success
> 
> real    0m0.111s
> user    0m0.000s
> sys     0m0.060s
> 
> $ time emacs-nox --batch -Q --eval '(kill-emacs)'
> 
> real    0m0.058s
> user    0m0.015s
> sys     0m0.030s
> 
> $ time ./emacs-fast $(cygpath -wa $(which emacs-nox.exe))
> Read 65536 bytes
> Success
> 
> real    0m0.148s
> user    0m0.015s
> sys     0m0.075s
> 
> $ time emacs-nox --batch -Q --eval '(kill-emacs)'
> 
> real    0m0.058s
> user    0m0.030s
> sys     0m0.015s
> 
> Ideas?
> Ryan

I can't repro it with the stock emacs-nox or emacs-X11 either, even as
administrator. But I can consistently repro it with any Emacs I build. More
bizarrely, if I take an emacs binary I've build and hardlink it into /bin, I can
repro the problem. If I _copy_ the binary instead of hardlinking it, I can't
repro, even though the copy has the same hard link count and ACL as the
hardlinked version.

The key to generating a binary that repros the problem is to unexec emacs, then
try to repro with that generated binary, not a copy of it. Maybe the process of
modifying the binary during unexec borks the system's ASLR cache; I can't
reproduce the problem with a simple testcase that copies and modifies the
binary, but my test doesn't actually change the binary --- it just writes back
to the destination binary exactly what we read from it.



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]