From: marcus AT bighorn DOT dr DOT lucent DOT com
Subject: Re: Time and motion studies of gcc and egcs and LCC
2 Feb 1998 15:33:38 -0800
Message-ID: <199802021515.IAA08872.cygnus.gnu-win32@chorus.dr.lucent.com>
To: gnu-win32 AT cygnus DOT com


>It occurred to me
>afterwards that the probable reason for this is linking to a DLL library
>or libraries for time-critical code.  If you get a profiler program that
>lets you know where gcc spends its time, I think you'll find that gcc is
>spending that extra time thunking back and forth between cygwin.dll.

I don't think that the overhead of getting into a DLL is all that great, so
I think that the performance hit is somewhere else, like inside cygwin.dll
and NT itself.  The cost to enter a DLL is an additional jump instruction
(indirect through the linkage pointer).  To return is no cost.  Granted, this
does bring an additional page into the working set (or two, actually, because
the linkage pointer is probably on a different page), but if the calls are
frequent, it should not be flushed frequently, so the page fault cost is
not very great either.

On Linux, is gcc linked with a static library or a shared library?  The cost
to enter a shared library is similar to a DLL.  Of course, cygwin32 has to
call into kernel32 & other NT DLLs, so there is a multiplication of costs
for cygwin32, but I still don't think that the DLL linkage costs are very
great.

marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".