Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!kddlab!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Keywords: ISC i386 shared libraries
Message-ID: <246@titccy.cc.titech.ac.jp>
Date: 27 May 91 10:53:10 GMT
References: <197@titccy.cc.titech.ac.jp> <1991May16.200702.7476@Think.COM> <209@titccy.cc.titech.ac.jp> <7974@auspex.auspex.com>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 27

In article <7974@auspex.auspex.com>
	guy@auspex.auspex.com (Guy Harris) writes:

>>You may remember that the speed of Bnews was actually improved by
>>in-lining the first part of strcmp(). In-lining of functions in
>>shared libraries is, of course, impossible.

>Well, in the version of Bnews we have here, that in-lining is done with
>a "STRCMP()" macro, that checks the first two characters and, only if
>they're not equal, calls "strcmp()".

Yes, of course. Bnews is the real example showing significance of call
overhead.

>Our Bnews programs are dynamically linked, and they have that in-lining;
>"In-lining of functions in shared libraries" is, of course, *NOT*
>"impossible", as demonstrated by that.

STRCMP() is source code level inlining of strcmp(), *NOT* strcmp()
in a shared library.

>Perhaps you want to completely delete the Bnews example, as it doesn't
>bolster your case,

Not at all.

						Masataka Ohta