From:	ian AT cygnus DOT com (Ian Lance Taylor)
Subject:	Re: Optimizing memset/memcpy/strcpy/etc.
16 Feb 1998 21:09:49 -0800 :
Message-ID:	<199802170509.AAA21136.cygnus.cygwin32.developers@subrogation.cygnus.com>
References:	<EoIB4n DOT AJ9 AT bbc DOT com>
Reply-To:	cygwin32-developers AT cygnus DOT com
To:	cgf AT bbc DOT com (Christopher Faylor)
Cc:	cygwin32-developers AT cygnus DOT com

   From: cgf AT bbc DOT com (Christopher Faylor)
   Date: Tue, 17 Feb 1998 04:57:59 GMT

   I tried that yesterday.  I pulled over the assembly versions of various
   commonly used routines from glibc into a separate 'memory.c' file and
   rebuilt Cygwin32.

   I was disappointed to notice no noticeable speed improvement.  It's hard
   to believe, but I really didn't see any difference in doing things like
   compiling a file in winsup.

My offhand guess would be that gcc on cygwin32 spends no more than,
say, 2% of its time in these routines, so even pushing their total
time to zero, which is impossible, would speed compilations up no more
than 2%.

Of course, that's just a guess.  What we really need is a profiler.  I
think somebody at Cygnus is working on a profiler, but I have no idea
how it is going.

   I guess that means that the most obvious speed improvement will probably
   come from optimizing the loading of dlls (somehow), like Sergey has
   suggested in the past.

Some of the posts on the gnu-win32 list have implied that Windows
always relocates DLLs if they have relocation information.  I would
hope that that is not true--if the DLL is loaded at the image address,
it should not be relocated.  Does anybody know exactly what Windows
does?  Perhaps there is something incorrect about the DLLs which
dlltool generates, which is leading Windows to always relocate them.
Or perhaps the messages on the mailing list have been wrong.

Ian

- Raw text -