This is the mail archive of the cygwin 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: Cygwin Performance and stat()


Christopher Wingert schrieb:
I assume POSIX compatibility.  However, I bet there are cases where one
can sacrifice compatibility for performance (configurable with an
environment flag of course).

See
http://marc.info/?l=git&m=122278284210941
for an example.

This git do_stat is for only meant for a 50% implementation of relative paths known before, and therefore onyl useful to certain apps, but it can never be useful for the cygwin1.dll layer, because cygwin has to provide the POSIX compat. layer, and not 50% cut-throughs for apps which don't need the other 50%. ACL, mounts, symlinks, inode.


A better chaching stat or an cygwin extension for relative deeper only would be possible, but a better caching stat would need more memory and sacrifice speed for the first stat.
A fast relative stat is very unlikely to be #IFDEF's in some apps just for us. So it's more likely that those apps which might need it, come up with their own 50% less, but 50% faster bits, as git did.


On Sun, May 30, 2010 at 08:54:10AM -0700, Christopher Wingert wrote:
I was looking into speeding up stat() performance.  More specifically
bash, ls, test, stat performance.  I've seen the subject come up before.
Git recently implemented a native Win32 work around.  Are there any
cygwin
patches around?

If there was a way to make stat() faster why wouldn't it be in the source code already?
--
Reini Urban
http://phpwiki.org/  http://murbreak.at/

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


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