Re: PATCH: speed up rtti decl emission

[Matt Austern <austern at apple dot com>]

On Sunday, March 16, 2003, at 01:15 PM, Mark Mitchell wrote:

> On Fri, 2003-03-14 at 10:32, Matt Austern wrote:
> > This patch changes emission of tinfo decls by creating a special list
> > for them, so that finish_file doesn't have to loop through every decl
> > in the whole program checking to see if it's a tinfo decl.  On Apple's
> > usual test case (-O0 -g build of the Finder, using PCH), it speed up
> > the build by a bit over 1%.  Not earthshaking, but every 1% helps!
>
> Indeed, and the concept here is good.
>
> One question: why not use two varrays (one for old tinfos, one for new
> ones), rather than the "push-at-the-end, then memcpy" idea?

Sorry if you're getting this twice, but I didn't see my previous email 
on
the list.  Resending my response...

Having two varrays was my original idea, but it turned out to be messier
than it seemed at first sight.  The important thing to realize is that
emit_tinfo_decl isn't just a harmless predicate.  It can itself push 
other
things onto the tinfo decl queue.  So if I were to have two varrays, I
would have to swap them at the right place (so that emit_tinfo_decl 
would
be pushing decls onto the new queue instead of the old one).  I would
also have to declare the auxiliary varray as a file-scope variable, even
though conceptually it would just be a local variable, to keep things gc
friendly.  (I don't *think* there's anything in the tinfo decl emission 
loop
that can result in ggc_collect getting called, but (a) I didn't want to 
try to
prove that; and (b) even if I proved it for the current front end, it 
could
always change as the compiler evolved.)

None of this is impossible; it's just that in my opinion the code to 
manage
two varrays correctly would be messier, and slightly harder to 
understand
and maintain, than the single-varray code that I used here.  The 
memmove/
memset code is mildly tricky, but at least all of the tricky part is 
localized
and confined to two or three lines.

			--Matt