Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Sun, 27 Jun 2004 15:42:05 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Cc: "Pierre A. Humblet" <pierre DOT humblet AT ieee DOT org>
Subject: Re: higher-level IO very slow with cygwin1.dll 5.10 (due to set_flags?)
Message-ID: <20040627194205.GA10371@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com, "Pierre A. Humblet" <pierre DOT humblet AT ieee DOT org>
References: <opr96vbqwilh6y6a AT localhost> <20040626154504 DOT GA961349 AT hpn5170x> <20040626160554 DOT GA980221 AT hpn5170x> <20040626170940 DOT GD20063 AT trixie DOT casa DOT cgf DOT cx> <20040626174145 DOT GA1032441 AT hpn5170x>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040626174145.GA1032441@hpn5170x>
User-Agent: Mutt/1.4.1i

On Sat, Jun 26, 2004 at 01:41:45PM -0400, Pierre A. Humblet wrote:
>On Sat, Jun 26, 2004 at 01:09:40PM -0400, Christopher Faylor wrote:
>> On Sat, Jun 26, 2004 at 12:05:54PM -0400, Pierre A. Humblet wrote:
>> >Beware, I found this:
>> >2000-05-19  DJ Delorie  <dj AT cygnus DOT com>
>> >	* libc/include/stdio.h: no getc/putc macros for cygwin; causes
>> >	compatibility issues with different dll versions
>> >so you may need to recompile when updating cygwin.
>> 
>> Also wouldn't that work around the file locks that were ostensibly put
>> there for a reason?
>
>That crossed my mind. But there is no file lock in the macro, which is
>used by systems other than cygwin. How do they manage it?
>I also assume that single threaded programs don't need the lock.
>
>I would be perfectly happy to have a thread-unsafe getc/putc macro,
>and to use fgetc/fputc when I care about multithreading.
>
>Digging deeper, I see there is a function getc_unlocked. Using it
>instead of getc improves the speed by a factor 5. 
>Now that I know about it, I will redefine getc to getc_unlocked when
>porting single threaded applications.
>
>That issue may be a factor in the legendary slowness of Cygwin.

FWIW, I added some code to this particular locking function to avoid
doing any locks if there is only one thread.  I'm generating a snapshot
now.  It will be interesting to see if it improves things.  I didn't
do any benchmarking.  I just verified that it worked the way I thought
it should by looking at strace output.

In the process of debugging this, I found that the version of cygwin
that I'd been building was not using any of the cygwin override functions
as are required for locking.  So, my personal cygwin was already pretty
fast -- at the expense of thread safety.  I'm going to be submitting
a patch to newlib to fix this problem.

So, please give today's snapshot a try.  I just uploaded a new one
a couple of minutes ago.

http://cygwin.com/snapshots.html

cgf

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