Mailing-List:	contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin-developers AT sources DOT redhat DOT com
Date:	Mon, 21 May 2001 15:40:24 -0400
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin-developers AT cygwin DOT com
Subject:	One source of recent cygwin slowdown
Message-ID:	<20010521154024.A15097@redhat.com>
Reply-To:	cygwin-developers AT cygwin DOT com
Mail-Followup-To:	cygwin-developers AT cygwin DOT com
Mime-Version:	1.0
User-Agent:	Mutt/1.3.11i

I did an exhaustive search of cygwin checkins last weekend to
attempt to determine the source of the 1.3.1 slowdown over 1.1.8.

I was surprised to find out that slowdown came about due to the
fhandler_dsp.cc checkin.  The slowdown was due to the Audio constructor
which was being called for a static use of the class.

Looking at the code, I don't see any obvious reason for a 10% slowdown
however, it is obvious that a normal user of the Cygwin DLL shouldn't be
suffering any performance consequences from the initialization of dsp
handling.  The alternative is to slow down cygwin every time we add a
new device.

My solution to this problem was to use a static pointer to the class that
is established only when /dev/dsp is opened.  I'm not sure if this is
the most elegant solution or if this will work correctly with fork.

It did result in a +10% improvement, though.

Just a cautionary note.

cgf

- Raw text -