Re: Optimizing memory footprint of bidi code

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Mon, 07 Jun 2010 12:01:26 -0400
> 
> > If so, this part is already taken care of.  If not, how to make this
> > type smaller without losing the benefits of an enumerated type (I
> > don't want to manipulate magic values or macros)?
> 
> I'm not sure what you're worried about.  What's wrong with adding a ":2"
> to the field?

Nothing's wrong.  I was saying that I would like to still be able to
use enumerated values and not just literal numerical constants.  But I
think Tom explained that with GCC this is not a problem.

> >   . struct bidi_it weighs in at 712 bytes on a 64-bit machine.  Can
> >     this amount of memory cause more frequent cache misses, with
> >     today's cache sizes?
> 
> If there's only one such struct used, then it's probably small enough
> that it doesn't matter.

There's only one such struct, it is part of struct it, the display
iterator used by redisplay.  Since windows are redisplayed one at a
time, there's only one instance of struct it and correspondingly only
one instance of struct bidi_it.

There's a cache inside bidi.c that caches bidi_it states.  That one
holds snapshots of struct bidi_it, but it is actively used only when
text actually needs reordering; otherwise, there's only one instance
there.  When reordering _is_ needed, the number of instances there
could be potentially large, but the intent of this cache is to prevent
repeated application of UAX#9 rules to characters we already saw and
processed.  This cache is on the heap.

> Of course, only measurements can give reliable answers.

I'd surely love to see some.