Re: [Bug-gnubg] bitfields

[Jim Segrave]

On Mon 25 Nov 2002 (13:25 -0500), Gary Wong wrote:
> On Mon, Nov 25, 2002 at 07:01:15PM +0100, Jim Segrave wrote:
> > Assuming (which may not be true) that there are relatively few
> > different evalcontexts active during any run of gnubg, then you could
> > replace storing the contexts with storing simply an index into a table
> > of pointers to copies of the setups, which would make the storage
> > requirements even smaller (and makes comparing setups and contexts
> > even faster), for what that might be worth.
> 
> Perfectly true, we could do that.  I seem to remember discussing the
> possibility of sharing evalcontexts with ref-counting semantics at the
> time we implemented moverecords, but we must have decided against it
> for one reason or another (presumably because the bookkeeping is
> slightly annoying and error-prone; another reason is that evalcontexts
> used to be smaller, comparable to the size of an integer/pointer,
> which isn't true any more).  I get the impression that your suggestion
> is to keep a copy of each evalcontext in a hash table even after it is
> unreferenced, which does look more appealing now that rolloutcontexts
> are significantly bigger than they used to be.

That sort of idea, yes. I haven't got any real design in mind, because
I haven't looked closely enough at what's being done and how they are
being used. I don't think there are that many evalcontexts live at any
given time - there are the ones created by initialisation, new ones
when the startup file is read, and ones created by users changing
settings. The cost of keeping a copy of each one and assigning it a
small index should not be that large. But I don't know how often they
are referenced for comparisions to know if there's really any profit
in that. 

I mistakenly thought this was already being done when I glanced at the
code in eval.c, but I see that that's keeping different information in
the evalcache structs. 

You get no savings when the actual context is being used, so the only
gains are execution time if there are a lot of compares and storage
space if there are a lot of copies being stored. 


-- 
Jim Segrave           address@hidden