This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]