Re: Turkeys and dynamic linking

* Kent Stewart <kstewart_at_owt.com> [031127 17:50]:
> On Thursday 27 November 2003 12:31 pm, Bill Moran wrote:
> > walt wrote:
> > > To all of you who celebrate Thanksgiving today, I wish you a happy one!
> > >
> > > And speaking of turkeys, does anyone know how Microsoft handles the
> > > performance issues associated with dynamic linking?  Do they do
> > > anything special, or just ignore the whole thing?
> >
> > Don't they fix the performance hit by moving performance-critical parts
> > of the application into kernel space (such as IIS and MSSQL)?
> >
> > At least, that's what Eric Raymond claims in his latest book.  I don't
> > think that's an approach I would like to see FreeBSD take.
> 
> It all depends because if you only have 1 dll loaded for multiple 
> applications, which is one of the features I understand is built into 
> Windows, you have real savings. You share the code and own the data.

Windows' dynamic linker works in a similar way to what Apple does in
terms of sharing dll code.  It makes an attempt to load libraries at the
same base address in all processes, so that one DLL can be easily mapped
into multiple processes.

When you build a DLL, you supply a "preferred address" where it should
be loaded.  If Windows can load the library there, it does so.  It also
tries to load DLL's in thh same order each time.

Since every process in the system likely relies on kernel32.dll, and
probably user32.dll and gdi32.dll and others, Windows is almost always
able to put those libraries at the same place in each process.  So it
doesn't have to read kernel32.dll from disk, since the OS itself has it
loaded from the beginning.  It just needs to do the fixups.

For user-defined libraries, there's a decent chance that the same thing
will happen.  If not, then you have to pay the penalty to remap the
library from scratch into a new location. 

As far as moving things into the kernel, I'm not sure what ESR is
referring to.  It's easy to get code into kernel-space by making it a
device driver, but AFAIK SQL Server code comes all from normal DLL
libraries, all in user space.

--Mike