This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PCH, and more generally C++ parser performance
>>>>> "Richard" == Richard Henderson <rth@cygnus.com> writes:
Richard> On Thu, Aug 24, 2000 at 06:40:47PM -0700, Mark Mitchell
Richard> wrote:
>> - Doing some kind of "freeze" on memory isn't entirely
>> unreasonable -- but it is hard. That brings us back to many of
>> the problems that we faced with obstacks.
Richard> It doesn't bring back obstack horror if you use the MMU
Richard> to enforce this sort of thing, which is what Zack was
Richard> mentioning.
Right. But do we want to require that the OS provide that kind of
capability? I guess we can always fall back on what we've already
got.
Richard> You guess that the memory is stable, mark it read-only,
Richard> and if you're wrong you get a SEGV, mark it read-write
Richard> again but now with knowledge that it must be rescaned.
Richard> It is still hard though.
Right. You have to remember not only that that memory is needed, but
what all else is needed because it is referenced from there. And if
that memory *is* written, you need to decide whether or not you want
to consider freeing the referenced memory. If you don't want to then
go rescan everything, you have to keep reference counts. (Ugh.)
It's not that there's nothing good down this path -- it's just that
deciding exactly how to do this is tricky. I'm a little afraid we're
putting the cart before the horse -- the last time I looked at C++
memory usage, there looked like there were still ways to get big
percentage eliminations in the total memory consumption. (Examples:
tree_identifier contains too many slots, most of which are unused, we
create lots of duplicate types for template parameters, lots of
duplicate template argument vectors, etc.)
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com