Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Sat, 28 May 2005 23:05:23 -0400
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Serious performance problems (new snapshot has some performance improvement)
Message-ID: <20050529030523.GA10263@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <000b01c563c7$f4456f00$976d65da AT DANNY> <4298F195 DOT 9090600 AT familiehaase DOT de> <20050529000152 DOT GE3094 AT trixie DOT casa DOT cgf DOT cx> <20050529001846 DOT GG3094 AT trixie DOT casa DOT cgf DOT cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050529001846.GG3094@trixie.casa.cgf.cx>
User-Agent: Mutt/1.5.8i

On Sat, May 28, 2005 at 08:18:46PM -0400, Christopher Faylor wrote:
>I have an idea about how to work around this problem but I have to think
>about how dangerous it might be.  Basically removing the signal handling
>wrapper around pthread_getspecific and pthread_setspecific.  That may
>work ok but I have to think about worst case scenarios.

I've semi-convinced myself that pthread_[gs]etspecific do not need signal
protection so I've released a snapshot which turns it off:

http://cygwin.com/snapshots/

This version is about 2.7 times faster than cygwin 1.5.17 but it is still
not as fast as mingw.  I don't think we're going to hit mingw performance
since there are still cygwin overhead issues involved.

AFAIK, this is only going to provide a speedup for this specific case.
I don't think a general cygwin user is going to notice any improvement.

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/