Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ernie.Berkeley.EDU!othar
From: othar@ernie.Berkeley.EDU (Othar Hansson)
Newsgroups: gnu.g++.lib.bug
Subject: lack of inline functions in libg++
Keywords: header inline class
Message-ID: <32147@ucbvax.BERKELEY.EDU>
Date: 25 Oct 89 06:17:56 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: othar@ernie.Berkeley.EDU (Othar Hansson)
Organization: University of California, Berkeley
Lines: 37

Before I rant, my thanks to the people who wrote the classes in
libg++.  You made my program work!  And reduced its size to a tenth of
that of the previous implementation.  Now for the whining...

I'm finding that I pay a real price in speed when I use some of the
libg++ library-derived classes.  For example, SplaySets are used
extensively in my code, and in a particularly crucial loop, elements
are retrieved from two SplaySets and multiplied -- my goal is to get
around that loop as many times as possible.

Unfortunately, functions like __SplaySet::next() cannot be inlined, as
they are not in the class header file -- they end up in another object
file.  This function call (and other accesses of different classes in
the same loop) costs me a significant constant in the speed around
that loop.  A lot of simple functions (even basic accesses like
class::operator[] and class::operator()) suffer from this same
problem, and they are precisely the functions that are called
thousands/millions of times in typical code.

While I wouldn't like to read an enormous header file for each
compilation, when I actually set my program running for 6 days, I
wouldn't mind the cost.  Can anyone think of a solution to this
problem?  

My initial modest proposal is that it would be nice if there were a
way to optionally GENCLASS a header with lots of inlines.
Alternately, there could be a compiler directive used in file X.cc, to
fetch a function from Y.cc for inlining in the compilation of X.s and
thence X.o.  The technology for doing this would probably enable lots
of other neat options as well...

        Tossing this out and hoping someone smarter than I will solve it,
        
                                                    Othar Hansson
                                                    CS Division
                                                    UC Berkeley
                                                    othar@ernie.berkeley.edu