Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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: Sat, 28 May 2005 17:18:44 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: Serious performance problems (malloc related?) Message-ID: <20050528211844.GD3094@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com References: <4297A14B DOT 9070409 AT plausible DOT org> <20050527234027 DOT GA7522 AT trixie DOT casa DOT cgf DOT cx> <4297B572 DOT 9050200 AT plausible DOT org> <20050528005054 DOT GB7522 AT trixie DOT casa DOT cgf DOT cx> <4297F984 DOT 3000800 AT plausible DOT org> <20050528061001 DOT GA9254 AT trixie DOT casa DOT cgf DOT cx> <42987F19 DOT 8070502 AT plausible DOT org> <4298D87F DOT 9030203 AT familiehaase DOT de> <20050528225007 DOT U63183 AT logout DOT sh DOT cvut DOT cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050528225007.U63183@logout.sh.cvut.cz> User-Agent: Mutt/1.5.8i On Sat, May 28, 2005 at 10:51:01PM +0200, Vaclav Haisman wrote: >On Sat, 28 May 2005, Gerrit P. Haase wrote: > >> Andy Ross wrote: >> > But as I noted in my original post: It's not waiting on the disk >> > reads. Comment out the split() call and watch the delays disappear. >> > Raw I/O speed in cygwin is comparable to mingw or MSVC. The overhead >> > is due, somehow, to activity within/under split(). Other than >> > allocation, that function doesn't do any meaningful library >> > interaction that I can see (although Vaclav's suggestion about >> > exception handling is a very good one...). >> >> Can you port the testcase you provided to C to see if it makes a >> difference, please? > >Or maybe at least try -fno-exceptions... I tried every variation of g++ exception switches that I could think of. It didn't make a difference. On further investigation, it sounds like the exception stuff is a red herring. It seems to have something to do with the fact that cygwin uses pthread_* and, apparently, pthread* is slow. It may be that cygwin calls in general are slow... 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/