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: slow share = slow scripts?


Christopher Faylor wrote:
On Fri, May 26, 2006 at 10:37:52AM -0500, mwoehlke wrote:
Way way back in the OP, I mentioned that Interix doesn't have this problem, which would imply a "design flaw" in Cygwin. Maybe (probably) it is a *necessary* design flaw, BUT...

A "necessary" design flaw? Interesting concept.

Well, sure... something that is known to be problematic (I think this qualifies) that is nevertheless necessary because of limitations in Windoze. At least, I would have to guess that the slow code is necessitated by Windows, since it works better on Interix and wonderfully on Linux.


$ time ./foo

real    0m0.296s
user    0m0.000s
sys     0m0.005s

This is a 50x difference where the difference should be minimal. That said, under Interix it still takes almost 2 seconds, which is 7x-ish difference, but still nowhere near 50x, so the problem isn't (entirely) the NFS client or the latency w.r.t. the share.

Summary:

exec time/ |  little |     big   |   stat
platform   |  script |    script |
-----------+---------+-----------+----------
Linux      |  0.296s |    1.105s | 0.122s(2)
Interix(1) |  1.828s |    5.536s |   (3)
Cygwin(1)  | 10.688s | 6m37.578s | 0.350s(4)

Notes:
1 - These are the same physical box.
2 - On Linux, 'stat' took the same amount of time on either script.
3 - My Interix installation apparently doesn't have 'stat', so this entry is blank.
4 - The time taken on Cygwin varied a lot, up to about 1s, and was a little (but not a lot) longer for the large script. 0.35s is roughly the lower bound (for both).


Note that both test computers are sitting next to each other, on the same unmanaged switch, talking to the same NFS share on the other side of the country (so the hops to get there should be identical). Clearly Windows' NFS client's performance is sub-par, but that is only to be expected. The question is; what is Cygwin doing - that neither Linux nor Interix do - that exasperates the problem so badly? Do I need to be going over strace's with a fine-toothed comb?

Clearly, the 6.5+ minute time is unacceptable*. For now I'm taking the 'copy everything locally' suggestion, but I would like to know why Cygwin performs several orders of magnitude(!) worse then either Linux or Interix. Also note that the 'stat' behavior seems to eliminate [f]stat() as the culprit, leaving the suspicious read()s without an obvious trigger.

(* "unacceptable" = "clearly this won't work, and I'll have to try something different")

Before Dave Korn decides to flame me (again), I am not asking for an immediate fix. I am posting my findings in case anything in them jumps out at someone else. I fully intend to track this down *myself* when I have the time to do so.

[snip] However, I would appreciate any existing
knowledge, or even pointers to where to start poking around, that anyone would care to share.

I think that most of the pointers and insight about what Cygwin does with fstat are all nicely encapsulated in the source code, specifically fhandler_disk_file.cc and fhandler.cc .

That qualifies as a pointer; thanks, I appreciate it. :-)


--
Matthew
Feed the hippo. Love the hippo. Run from the hippo.


-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/


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