First of all, although this patch passes the testsuite, I don't
think it is ready to go in, at least not without a thorough
discussion of its downsides.
What the patch does is move away from using unique_ptr<>s to
track DIE object memory and allocate most of them using a
BumpAllocator. Making releasing the memory for the DIE tree
basically free. (DIEBlocks and DIELocs are still allocated using
the standard allocator, but they were already using separate
bookkeeping, so this doesn't complicate the patch).
I'm going down this road because the teardown of the DIE tree
uses a lot of CPU time, especially in dsymutil's usecase. In
my prototype, the DIE destructors take ~40 seconds to run for
DIE trees worth of 700MB of debug infomration. That's quite a
lot especially considering that dsymutil's runtime on this kind
of data should be around 2 minutes. I really need to find an
acceptale solution for dsymutil's usecase.
This patch achieves the performance gains that I expect, but there
is one big downside: it limits the number of attributes a DIE can
accept to a fixed maximum (well technically, if you remove the
assert in the code, it will work, but it will leak the attribute
vectors going over the limit).
Imposing this limit on users seems too strong as a constraint.
Especially considering not all frontends are in-tree. I can imagine
more flexible solutions involving complicated allocation strategies,
but I wanted to ask for opinions before I work on something that I
fear would end up much more complicated than this patch. Maybe
there's an easier solution that I haven't seen, happy to hear
suggestions.
BTW, the runtime difference is definitely measurable on a clang
debug build also, although the gained seconds do not represent
40% of the runtime like in dsymutil's case. On my machine, a clang
debug build goes from:
real 14m38.308s
user 45m26.856s
sys 3m53.519s
without the patch, to:
real 14m19.762s
user 44m14.438s
sys 3m45.520s
Shaving more than one minute of user time and 15 to 20 seconds from
wall-clock time.
This might be able to be private inheritance? (just handle the DIEs by unique_ptr and then pass them into addChild)
Hmm, I suppose it'd need to friend the ilist instantiation & maybe other things, for this to be private inheritance?