delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/04/15/20:23:01

From: ian AT cygnus DOT com (Ian Lance Taylor)
Subject: Re: New import library format proposal.
15 Apr 1998 20:23:01 -0700 :
Message-ID: <199804160254.WAA20349.cygnus.cygwin32.developers@subrogation.cygnus.com>
References: <01BD68CB DOT 224726A0 AT sos>
To: sos AT buggy DOT prospect DOT com DOT ru
Cc: cygwin32-developers AT cygnus DOT com

   From: Sergey Okhapkin <sos AT buggy DOT prospect DOT com DOT ru>
   Date: Thu, 16 Apr 1998 00:03:04 +0400

   I designed this import library format to speed-up process startup. No 
   exports are linked statically, all dll symbols (except LoadLibrary() and 
   GetProcAddres() in libkernel32.a) are resolved dynamically on demand. I 
   hope this should speed-up the startup time of a process. Actual linking is 
   performed only on the first call of dll-exported function, the next calls 
   are a bit faster than in a current implementation (direct jump instead of 
   indirect jump). Dll-exported datas should be accessed/imported in a old 
   (current) way. Library files will have a smaller size than now. New format 
   is compatible with old object files.

Very Unix like.

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.

However, before checking this in, I'd be interested in hearing what
kind of performance improvement you get.

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.

Ian

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019