Mail Archives: cygwin-developers/1998/04/16/08:03:38
From: Sergey Okhapkin <sos AT prospect DOT com DOT ru>
Date: Thu, 16 Apr 1998 11:15:26 +0400
Ian Lance Taylor wrote:
> Besides the function name, you can include a pointer to a structure
> holding the DLL name and the static variable holding the library
> HANDLE. Then we don't have to have separate do_call$dllname
> functions, and can instead have a single one in libcygwin.a.
Don't do it... This will make new-style import libraries cygwin-specific.
Separate do_call functions in each library will allow to use the libraries
with non-cygwin code (mingw32, for example, or with other compilers). I
talk about system dlls mainly.
How about including the generic function in a COMDAT section in the
library?
> However, before checking this in, I'd be interested in hearing what
> kind of performance improvement you get.
I didn't try it :-) It's just my crazy dreams... But we have now a good
example - 20% increase of speed due to on demand loading of wsock32.dll in
cygwin. The next thing I want to think about, is an access to dll-exported
datas.
The speed up of loading wsock32.dll is not a good example of the speed
up we will get from this change. With this change we will still need
to actually load the DLLs. The cygwin DLL now only references three
DLLs: kernel32, advapi32, and user32. I expect that even under your
scheme pretty much any program will load all three DLLs; certainly the
first two will be loaded by the process startup code in dll_crt0_1.
So the speed up from your scheme is not the loading of the DLL, but
only the symbol resolution.
> It seems to me that we could change the linker to set up the import
> address table with the DLL timestamp. That should reduce symbol
> resolution time to zero, and might well be faster still.
This will work for cygwin-compiled dlls, but what to do with a system dlls?
The slowness of process startup is mainly in linking cygwin.dll with a
system dlls. System dlls on NT and W9X have different timestamps, updated
dlls in service packs have a different timestamps too... It's a MS way :-)
My understanding is that MS has a program, editbin, which will set up
the import address table and timestamps of a given executable or DLL
for your system. People concerned about performance can run that. We
could even provide our own version of that program. We could even run
it automatically during installation time.
Ian
- Raw text -