Re: [PATCH] Reduce GC overhead of the C++ lexer buffer

[Richard Guenther <rguenther at suse dot de>]

On Mon, 19 Jun 2006, Mark Mitchell wrote:

> Richard Guenther wrote:
> > At the moment we have
> > 
> > cp/parser.c:292 (cp_lexer_new_main)  0: 0.0%  82369152:33.3%  0: 0.0% 
> > 15784576:37.2%  7
> > 
> > which is due to the fact that the initial lexer buffer size is no where
> > near a power-of-two value and we keep gc-reallocating the vector, doubling
> > its size.
> > 
> > With the following patch, this overhead is removed nearly completely
> > 
> > cp/parser.c:266 (cp_lexer_new_main)                       0: 0.0%         
> > 36: 0.0%          0: 0.0%          4: 0.0%          1
> > 
> > Comments?
> 
> This is a good result -- but what test case did you use?  Also, can you
> explain why it's important to use a power of two here?  Is it because
> that avoids having to copy data to new kernel pages, or something?
> 
> > ! #define CP_LEXER_BUFFER_SIZE (262144/sizeof(cp_token))
> 
> Please right as "256 * 1024" rather than as 262144 to make it obvious
> that this is a power-of-two; not everyone knows there powers up that
> high.  Also, why not just right 8 * 1024?  Why does it make sense to use
> 256K/sizeof?

CP_LEXER_BUFFER_SIZE is the number of elements in the cp_token GGC vector:

  /* Create the buffer.  */
  alloc = CP_LEXER_BUFFER_SIZE;
  buffer = GGC_NEWVEC (cp_token, alloc);

to reduce the GC overhead (the unused part at the end of a GC page), the
amount of memory allocated needs to be (close to) a power of two.  Thus
the division by sizeof(cp_token).  The number 262144 was chosen to be
a reasonable compromise between 32bits (20 bytes per cp_token) and 64bits
(larger), so that the number of initial tokens is around the original
value 10000.  But I can easily halve this number, if requested.

Bootstrapped and tested on x86_64-unknown-linux-gnu, btw. (forgot to say
that in the previous mail).

Thanks,
Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs