Re: Minor speedup

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <16915.1023542749@porcupine.cygnus.com> you write:
>In message <20020608044530.J13411@devserv.devel.redhat.com>, Jakub Jelinek writ
>es:
> > On Fri, Jun 07, 2002 at 12:03:38PM -0600, law@redhat.com wrote:
> > > 
> > > I got some interesting data yesterday from profiling the PA port building
> > > my 162 testfiles at -O2.  Here's a trivial fix which improves compile time
> > s
> > > by just shy of 1%.
> > > 
> > > Basically we're doing an insane number of calls into free_INSN_LIST_list,
> > > on the order of 90 million.  Roughly 55 million are calls to free an empty
> > > list from within free_deps.  Opps.
> > 
> > But then for the remaining 35 million calls the list is checked for NULL
> > twice. Wouldn't be better to go over gcc sources and put performance critica
> > l
> > very short routines into headers as inlines (provided we're building
> > with gcc and optimizing)?
>Basically we'd have to expose the free element cache outside lists.c which
>seems like a bad idea.  We use this cache to avoid lots of silly 
>allocations.

That's only because C is a lousy language.
What's the problem in exposing that stuff, AND giving a clean interface,
and not accepting any code that doesn't go through the required interface ?

(kind of stuff that would be dead trivial to enforce in C++...)

Seriously:
- it doesn't decrease maintainability. You still go through accessor
functions. Only bad hackers who never read the docs will try to bypass it,
and we don't have to cater to them, and their code can be allowed to die
the atrocious death it deserves.
- we already found out that gcc has become dog-slow.  Any hack that is
maintainable and regains some of the lost speed ought to be a good thing,
no ?