From: sos AT prospect DOT com DOT ru (Sergey Okhapkin) Subject: RE: Optimizing memset/memcpy/strcpy/etc. 18 Feb 1998 00:56:16 -0800 Message-ID: <01BD3C55.6A6EB990.cygnus.cygwin32.developers@gater.krystalbank.msk.ru> To: "'Ian Lance Taylor'" Cc: "cygwin32-developers AT cygnus DOT com" Ian Lance Taylor wrote: > > 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. How ld and dlltool creates hint numbers? MS linker builds a dll and an import library in one pass and uses current time for hint number. NT's loader never uses ordinal numbers if hints in a dll and executable do not match, it performs name lookups this case. > 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. This will require rebuild of all binaries with new libcygwin.a after rebuilding cygwin.dll :-( > > 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. We shouldn't even think about it:-( I'm sure that ordinal numbers and hints differs in different versions of Windows. Every service pack for NT replaces some main dlls with a new ones, with different hints. > 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. It's the same I wrote about some time ago! Unfortunately, the bug in g++ parcer prevents from doing this changes :-( > > Again, I don't know how much time would be saved by omitting this. I tried this - just replaced winsock calls with my dummy functions, and linked this file instead of libwsock32.a to cygwin.dll. Configure scripts ran about 20-25% faster. > 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. Serial port functions are imported from kernel32.dll. Cygwin uses very many imports from this dll, and this library must be linked statically. A good candidates for dynamic loading are wsock32.dll and user32.dll (cygwin uses about 10 imports from this dll). -- Sergey Okhapkin, http://www.lexa.ru/sos Moscow, Russia Looking for a job.