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
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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