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/11/2012 08:13 PM, Daniel Colascione wrote:
> On 12/11/2012 5:06 PM, Daniel Colascione wrote:
>> On 12/10/2012 7:51 PM, Daniel Colascione wrote:
>>> 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.
>>
>> The real explanation is a lot simpler: the binary is sparse. When you create a
>> file mapping object for a sparse file, Windows discards all cached pages for
>> that file. It makes sense that compilers (and Emacs unexec) would create sparse
>> files as they seek around inside their outputs.
> 
> Anyway, the binary is sparse because our linker produces sparse files.
> 
> Would the Cygwin developers accept this patch? With it, applications would need
> to explicitly use ftruncate to make files sparse.

Eww.  That would be a regression for coreutils, and a waste of disk
space for files where sparse is a benefit.

> Considering the horrible and
> unexpected performance implications of sparse files, I don't think generating
> them automatically from a sequence of seeks and writes is the right thing to do.

Why can't we instead use posix_fallocate() as a means of identifying a
file that must not be sparse, and then just patch the compiler to use
posix_fallocate() to never generate a sparse executable (but let all
other sparse files continue to behave as normal)?

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

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]