Mail Archives: cygwin-developers/1998/02/17/10:00:04
From: Sergey Okhapkin <sos AT prospect DOT com DOT ru>
Date: Tue, 17 Feb 1998 10:34:44 +0300
Ian Lance Taylor wrote:
> 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
It seems to me not true. Windows (at least NT) relocates a dll only if
address space is in use by any other dll/stack/program code/alloced memory.
But dll reallocation is not only slowness of process startup, another one
is linking of application/dll imports/exports - it's really slow process -
for every import loader performs a binary search of corresponding dll's
export by name.
Unix dynamic linkers do this as well, except that they use a hash
table for symbol lookup, and it doesn't seem to be a big problem. You
can measure the dynamic linking startup time, and it's not bad for
typical programs.
If the symbol lookup is slow, then there are two different approaches
we could use to speed things up: import symbols by ordinal number, or
only lookup symbols when we need them.
The import table in an executable or DLL has an ordinal hint field.
The Windows loader is supposed to use that first when looking up the
symbol in the DLL export table. Comparing the hint fields I find in a
binary linked against the cygwin DLL against the export symbol table,
both as printed by objdump -p, I find that they don't match. The
numbers in the hint field are not the export symbol numbers.
It's quite possible that objdump is printing the wrong information,
and it's quite possible that I'm misunderstanding something. However,
this suggests that one way to speed up the start up time is to get the
linker and dlltool to cooperate in whatever way is required to get the
hint numbers right. That will at least save the time required to look
up symbols in the cygwin DLL itself.
We may also be able to get the hint numbers right for the main Windows
DLLs. It seems likely enough that Windows would use the same ordinal
numbers for the main DLLs, so that importing by ordinal number would
work correctly. If that is so, we should be able to make our
libraries contain the same ordinal numbers as hints, and thus save the
lookup time for importing symbols from the popular Windows DLLs.
Not that I'm not recommending that we start importing by ordinal
number rather than by name. That seems likely to be error prone. I'm
suggesting that if we can usually get the hint numbers right, it will
permit the Windows loader to avoid the binary search on the symbol
name.
Does anybody have a sense of how much time this would actually save?
Looking up symbols by name only as when they are required would be
useful in certain specific circumstances. As I see it, it would
mainly help for the cygwin DLL itself. For example, the cygwin DLL
imports a bunch of socket functions from wsock32.dll. Those are not
used by programs that don't use sockets, and so the time that the
Windows loader spends in tracking down wsock32.dll and resolving all
the symbol references is wasted for many programs.
Again, I don't know how much time would be saved by omitting this.
This sort of improvement would be quite easy to implement in the case
of sockets. There may be some other specific sets of functions which
can be looked up in this manner. The serial port functions, for
example, although there aren't too many such functions.
Ian
- Raw text -