This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
- From: "Pierre A. Humblet" <pierre dot humblet at ieee dot org>
- To: cygwin at cygwin dot com
- Date: Sat, 26 Jun 2004 11:45:04 -0400
- Subject: Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
- References: <opr96vbqwilh6y6a@localhost>
On Sat, Jun 26, 2004 at 02:36:52AM -0400, Joseph wrote:
> Thanks to those who responded to my post.
>
> I am not sure though if all of you read the
> entire sequence of the thread.
>
> In my first post, I did attach an excerpt
> from an strace dump of a sample program that
> seemed to show "where the time is going".
You initial accusation against set_flags was unfounded
and led nowhere. But you have a very good point.
Your "fast" program is doing reads in blocks of 1024.
Your "slow" program is using getc.
I observed that the slow program was 20 times slower
than the fast one, even though strace showed that getc
was properly calling read in blocks of 1024.
I then noticed that getc is not implemented as a macro
on Cygwin. It's a newlib function
74 int
75 _DEFUN(getc, (fp),
76 register FILE *fp)
77 {
78 int result;
79 _flockfile (fp);
80 /* CHECK_INIT is called (eventually) by __srefill. */
81 result = __sgetc (fp);
82 _funlockfile (fp);
83 return result;
(gdb)
84 }
_flockfile calls a bunch of pthread functions. That's where all
the time is spent, a large part of it verifying that pointers
are valid.
It's probably a relatively new feature of Cygwin. Others may know
more about the history and justification of implementation.
Pierre
--
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/