This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Cygwin Performance and stat()
- From: Eliot Moss <moss at cs dot umass dot edu>
- To: cygwin at cygwin dot com
- Date: Tue, 01 Jun 2010 19:49:50 -0400
- Subject: Re: Cygwin Performance and stat()
- References: <efe8a37b2e4466daa7b6eb1aa610c3d7.squirrel@www.webmail.wingert.org> <20100530170747.GA8605@ednor.casa.cgf.cx> <f460895a8fc53da26cb91259a4005da2.squirrel@www.webmail.wingert.org> <4C03D6C5.4050004@x-ray.at> <80373222dd5d43b134a5ede7036e7674.squirrel@www.webmail.wingert.org> <4C058753.1030400@cygwin.com>
- Reply-to: moss at cs dot umass dot edu
On 6/1/2010 6:18 PM, Larry Hall (Cygwin) wrote:
Thanks for this information and perhaps I'm wrong but I don't believe
anyone in this thread thought that you were lying when you noted issues
with the performance of stat(). ;-) But providing a variant of stat()
along the lines of what you propose above is not practical for all the
reasons already stated. I believe we would all like stat() to be
quicker but we need something that solves the root of the problem and
not partial, hidden solutions that are problematic to use.
Agreed. But here's a wondering. What if, perhaps via autoconf flags
or something (I know next to nothing about autoconf, so please ignore
that part of it if it is completely off base), we could make it
possible for someone who is porting a package to cygwin to indicate
what features of stat that program needs. This would be optional
to do, and could be applied as porters have time, etc. Now ideally
such an approach could be applied differentially to different calls
of stat, but even if it is global, maybe it would help speed up
some programs a lot ...
Again, just wondering about whether something like this might
get the community somewhere better in performance ...
Regards -- Eliot Moss
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple