«

On Apr 27, 2:56*pm, jacob navia <ja...@spamsink.net> wrote:
> Le 27/04/11 21:01, Pete Becker a crit :
>
>
>
>
>
>
>
>
>
> > On 2011-04-27 14:24:21 -0400, Ebenezer said:
>
> >> On Apr 25, 4:53 pm, James Kanze <james.ka...@gmail.com> wrote:
> >>> On Apr 25, 6:16 pm, Victor Bazarov <v.baza...@comcast.invalid> wrote:
>
> >>>> There are linkers that will remove unused functions from the
> >>>> object modules (so you're going to end up with "1"). *Other
> >>>> linkers will leave in the entire object module (so you're
> >>>> getting "2" or "3" depending on how your code is organised).
>
> >>> The granularity of most linkers is the object file. *In general,
> >>> if you are writing a library, you put each non-virtual function
> >>> in a separate object file, and only those which are actually
> >>> called are included. *(But this is, of course, a quality of
> >>> implementation issue for the library provider.)
>
> >> This seems like a "premature optimization." I haven't come
> >> across this much, but recall your mentioning it previously.
>
> > Not in a general-purpose library. If you get it wrong your customers
> > complain about code bloat. As an extreme example, linking the entire C
> > standard library into every application would not be a good thing.
>
> For some people all optimizations are "premature" and they deliver
> bloated, unoptimized programs. Code bloat slows down programs because
> it forces more main memory reads, and makes code cacheing less
> efficient. It is a very important optimization.


I think this library -- http://quicklz.com -- is a
quality library, but there's no breaking things up
like that. I can't think of a library that splits
things up into such small chunks.

In article <c18b2cb6-1106-4dfc-86d1->
Ebenezer <> writes:
>On Apr 27, 2:56*pm, jacob navia <ja...@spamsink.net> wrote:
>> Le 27/04/11 21:01, Pete Becker a crit :
>>
>> > On 2011-04-27 14:24:21 -0400, Ebenezer said:
>>
>> >> On Apr 25, 4:53 pm, James Kanze <james.ka...@gmail.com> wrote:
>>
>> >>> The granularity of most linkers is the object file. *In general,
>> >>> if you are writing a library, you put each non-virtual function
>> >>> in a separate object file, and only those which are actually
>> >>> called are included. *(But this is, of course, a quality of
>> >>> implementation issue for the library provider.)
>>
>> >> This seems like a "premature optimization." I haven't come
>> >> across this much, but recall your mentioning it previously.
>>
>> > Not in a general-purpose library. If you get it wrong your customers
>> > complain about code bloat. As an extreme example, linking the entire C
>> > standard library into every application would not be a good thing.
>>
>> For some people all optimizations are "premature" and they deliver
>> bloated, unoptimized programs. Code bloat slows down programs because
>> it forces more main memory reads, and makes code cacheing less
>> efficient. It is a very important optimization.
>
>
>I think this library -- http://quicklz.com -- is a
>quality library, but there's no breaking things up
>like that. I can't think of a library that splits
>things up into such small chunks.

Taking a quick look at libc on my FreeBSD system, I see that it is
split into 849 files. I find this pretty common for general use
libraries.
Less general libraries -- database APIs, toolsets, etc. -- probably
don't take that effort as often.

--
Drew Lawson | And to those who lack the courage
| And say it's dangerous to try
| Well they just don't know
| That love eternal will not be denied

On Apr 28, 2:23*pm, d...@furrfu.invalid (Drew Lawson) wrote:
> In article <c18b2cb6-1106-4dfc-86d1-2b803b060...@w24g2000yqb.googlegroups..com>
> * * * * Ebenezer <woodbria...@gmail.com> writes:
>
>
>
>
>
>
>
>
>
> >On Apr 27, 2:56 pm, jacob navia <ja...@spamsink.net> wrote:
> >> Le 27/04/11 21:01, Pete Becker a crit :
>
> >> > On 2011-04-27 14:24:21 -0400, Ebenezer said:
>
> >> >> On Apr 25, 4:53 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> >> >>> The granularity of most linkers is the object file. In general,
> >> >>> if you are writing a library, you put each non-virtual function
> >> >>> in a separate object file, and only those which are actually
> >> >>> called are included. (But this is, of course, a quality of
> >> >>> implementation issue for the library provider.)
>
> >> >> This seems like a "premature optimization." I haven't come
> >> >> across this much, but recall your mentioning it previously.
>
> >> > Not in a general-purpose library. If you get it wrong your customers
> >> > complain about code bloat. As an extreme example, linking the entireC
> >> > standard library into every application would not be a good thing.
>
> >> For some people all optimizations are "premature" and they deliver
> >> bloated, unoptimized programs. Code bloat slows down programs because
> >> it forces more main memory reads, and makes code cacheing less
> >> efficient. It is a very important optimization.
>
> >I think this library --http://quicklz.com-- *is a
> >quality library, but there's no breaking things up
> >like that. *I can't think of a library that splits
> >things up into such small chunks.
>
> Taking a quick look at libc on my FreeBSD system, I see that it is
> split into 849 files. *I find this pretty common for general use
> libraries.
> Less general libraries -- database APIs, toolsets, etc. -- probably
> don't take that effort as often.

running

nm /usr/lib/libc.a | grep -F ".o:" | wc -l

on this Ubuntu Linux box suggests 1479 distinct ibject files in the
static library

nm /usr/lib/libc.a 2> /dev/null | grep " T " | wc -l

suggests 2377 defined global symbols, or about 1.5 exported symbols
per object file.

On Apr 28, 7:01*am, gwowen <gwo...@gmail.com> wrote:
> On Apr 28, 2:23*pm, d...@furrfu.invalid (Drew Lawson) wrote:
>
>
>
>
>
>
>
>
>
> > In article <c18b2cb6-1106-4dfc-86d1-2b803b060...@w24g2000yqb.googlegroups.com>
> > * * * * Ebenezer <woodbria...@gmail.com> writes:
>
> > >On Apr 27, 2:56 pm, jacob navia <ja...@spamsink.net> wrote:
> > >> Le 27/04/11 21:01, Pete Becker a crit :
>
> > >> > On 2011-04-27 14:24:21 -0400, Ebenezer said:
>
> > >> >> On Apr 25, 4:53 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > >> >>> The granularity of most linkers is the object file. In general,
> > >> >>> if you are writing a library, you put each non-virtual function
> > >> >>> in a separate object file, and only those which are actually
> > >> >>> called are included. (But this is, of course, a quality of
> > >> >>> implementation issue for the library provider.)
>
> > >> >> This seems like a "premature optimization." I haven't come
> > >> >> across this much, but recall your mentioning it previously.
>
> > >> > Not in a general-purpose library. If you get it wrong your customers
> > >> > complain about code bloat. As an extreme example, linking the entire C
> > >> > standard library into every application would not be a good thing.
>
> > >> For some people all optimizations are "premature" and they deliver
> > >> bloated, unoptimized programs. Code bloat slows down programs because
> > >> it forces more main memory reads, and makes code cacheing less
> > >> efficient. It is a very important optimization.
>
> > >I think this library --http://quicklz.com--*is a
> > >quality library, but there's no breaking things up
> > >like that. *I can't think of a library that splits
> > >things up into such small chunks.
>
> > Taking a quick look at libc on my FreeBSD system, I see that it is
> > split into 849 files. *I find this pretty common for general use
> > libraries.
> > Less general libraries -- database APIs, toolsets, etc. -- probably
> > don't take that effort as often.
>
> running
>
> nm /usr/lib/libc.a | grep -F ".o:" | wc -l
>
> on this Ubuntu Linux box suggests 1479 distinct ibject files in the
> static library
>
> nm /usr/lib/libc.a 2> /dev/null | grep *" T " | wc -l
>
> suggests 2377 defined global symbols, or about 1.5 exported symbols
> per object file.

An easier way to do it:

On RHEL 5,

ar tv /usr/lib/libc.a | wc

shows 1391 object files

On Apr 28, 9:01*am, gwowen <gwo...@gmail.com> wrote:
> On Apr 28, 2:23*pm, d...@furrfu.invalid (Drew Lawson) wrote:
>
>
>
>
>
>
>
>
>
> > In article <c18b2cb6-1106-4dfc-86d1-2b803b060...@w24g2000yqb.googlegroups.com>
> > * * * * Ebenezer <woodbria...@gmail.com> writes:
>
> > >On Apr 27, 2:56 pm, jacob navia <ja...@spamsink.net> wrote:
> > >> Le 27/04/11 21:01, Pete Becker a crit :
>
> > >> > On 2011-04-27 14:24:21 -0400, Ebenezer said:
>
> > >> >> On Apr 25, 4:53 pm, James Kanze <james.ka...@gmail.com> wrote:
>
> > >> >>> The granularity of most linkers is the object file. In general,
> > >> >>> if you are writing a library, you put each non-virtual function
> > >> >>> in a separate object file, and only those which are actually
> > >> >>> called are included. (But this is, of course, a quality of
> > >> >>> implementation issue for the library provider.)
>
> > >> >> This seems like a "premature optimization." I haven't come
> > >> >> across this much, but recall your mentioning it previously.
>
> > >> > Not in a general-purpose library. If you get it wrong your customers
> > >> > complain about code bloat. As an extreme example, linking the entire C
> > >> > standard library into every application would not be a good thing.
>
> > >> For some people all optimizations are "premature" and they deliver
> > >> bloated, unoptimized programs. Code bloat slows down programs because
> > >> it forces more main memory reads, and makes code cacheing less
> > >> efficient. It is a very important optimization.
>
> > >I think this library --http://quicklz.com--*is a
> > >quality library, but there's no breaking things up
> > >like that. *I can't think of a library that splits
> > >things up into such small chunks.
>
> > Taking a quick look at libc on my FreeBSD system, I see that it is
> > split into 849 files. *I find this pretty common for general use
> > libraries.
> > Less general libraries -- database APIs, toolsets, etc. -- probably
> > don't take that effort as often.
>
> running
>
> nm /usr/lib/libc.a | grep -F ".o:" | wc -l
>
> on this Ubuntu Linux box suggests 1479 distinct ibject files in the
> static library
>
> nm /usr/lib/libc.a 2> /dev/null | grep *" T " | wc -l
>
> suggests 2377 defined global symbols, or about 1.5 exported symbols
> per object file.

Thanks for the commands. What about the little " t "'s in nm output?

I checked my library like you did with libc and got a ratio of 4.

On Apr 27, 6:49*pm, Ebenezer <woodbria...@gmail.com> wrote:
> On Apr 27, 3:00*pm, "Bo Persson" <b...@gmb.dk> wrote:
>
> > Ebenezer wrote:
> > > On Apr 25, 4:53 pm, James Kanze <james.ka...@gmail.com> wrote:
> > >> The granularity of most linkers is the object file. In general,
> > >> if you are writing a library, you put each non-virtual function
> > >> in a separate object file, and only those which are actually
> > >> called are included. (But this is, of course, a quality of
> > >> implementation issue for the library provider.)
>
> > > This seems like a "prematureoptimization." *I haven't come
> > > across this much, but recall your mentioning it previously.
>
> > Some compilers will do it for you, and put each function in its own
> > section. Perhaps that's why not everyone have noticed any "bloat".
>
> What compilers do this?

I'd like to give a shout out to the vendors that have done
things right in this regard. Who are the good guys in this
story?

I've made some changes to my work related to this.
Previously I had this "middle" file:

local_messages
(cmw_request)

(bool)
(bool, flex_string<char>) @out
(flex_string<char>) @in
}

----------------------------------------------------

A line like (cmw_request) caused both a Send and
Receive function to be created. And the class
that was created, local_messages, was shared by
two executables. Now I've changed the middle file
so two separate classes are created:

local_messages
(cmw_request) @in

(bool) @out
(bool, flex_string<char>) @out
}

local_messages_d
(cmw_request) @out

(bool) @in
(flex_string<char>) @in
}

-------------------------------------------------

Using this approach has reduced the size of the
two executables by 300 to 400 bytes each. It also
provides a nice application of the support for
multiple classes being outlined in a middle file.


Brian Wood

Ebenezer wrote:

> On Apr 27, 3:00*pm, "Bo Persson" <b...@gmb.dk> wrote:

>> Some compilers will do it for you, and put each function in its own
>> section. Perhaps that's why not everyone have noticed any "bloat".
>
> What compilers do this?

For instance:
gcc -ffunction-sections

(I don't know what compilers do it by default)

On May 4, 12:04*pm, Marc <marc.gli...@gmail.com> wrote:
> Ebenezer *wrote:
> > On Apr 27, 3:00*pm, "Bo Persson" <b...@gmb.dk> wrote:
> >> Some compilers will do it for you, and put each function in its own
> >> section. Perhaps that's why not everyone have noticed any "bloat".
>
> > What compilers do this?
>
> For instance:
> gcc -ffunction-sections
>


I just tried that with the combined/shared class I mentioned.
Unfortunately, the sizes of the executables are not reduced
by that option. I used -ffunction-sections when building
the object files and the executables. I didn't do anything
different when building the library.

Op 28-Apr-11 1:49, Ebenezer schreef:
> On Apr 27, 3:00 pm, "Bo Persson"<b...@gmb.dk> wrote:
>> Ebenezer wrote:
>>> On Apr 25, 4:53 pm, James Kanze<james.ka...@gmail.com> wrote:
>>>> On Apr 25, 6:16 pm, Victor Bazarov<v.baza...@comcast.invalid>
>>>> wrote:
>>
>>>>> There are linkers that will remove unused functions from the
>>>>> object modules (so you're going to end up with "1"). Other
>>>>> linkers will leave in the entire object module (so you're
>>>>> getting "2" or "3" depending on how your code is organised).
>>
>>>> The granularity of most linkers is the object file. In general,
>>>> if you are writing a library, you put each non-virtual function
>>>> in a separate object file, and only those which are actually
>>>> called are included. (But this is, of course, a quality of
>>>> implementation issue for the library provider.)
>>
>>> This seems like a "premature optimization." I haven't come
>>> across this much, but recall your mentioning it previously.
>>
>> Some compilers will do it for you, and put each function in its own
>> section. Perhaps that's why not everyone have noticed any "bloat".
>
> What compilers do this?

Even Microsoft Visual C++ 6.0, which was released well over a decade
ago, could do this.

On 4 mai, 20:03, Ebenezer <woodbria...@gmail.com> wrote:
> On May 4, 12:04*pm, Marc <marc.gli...@gmail.com> wrote:
> > Ebenezer *wrote:
> > > On Apr 27, 3:00*pm, "Bo Persson" <b...@gmb.dk> wrote:
> > >> Some compilers will do it for you, and put each function in its own
> > >> section. Perhaps that's why not everyone have noticed any "bloat".
> > > What compilers do this?
> > For instance:
> > gcc -ffunction-sections
> I just tried that with the combined/shared class I mentioned.
> Unfortunately, the sizes of the executables are not reduced
> by that option.

You may also want to look at the --gc-sections option of ld.