Re: freeing srcprops ?

[Han-Wen Nienhuys]

Neil Jerram escreveu:
> Kevin Ryde <address@hidden> writes:
> 
>> Han-Wen Nienhuys <address@hidden> writes:
>>> why use a separate storage pool for srcprop objects?
>> At a guess, is it because that they're likely to never need freeing,
>> hence can be laid down in big blocks.
> 
> I'd guess because setting up a srcprops is critical to start-up
> performance, and a double cell doesn't have enough slots to store all
> the common properties (filename, pos, copy) directly (as your change
> makes clear).

All this guessing ...  I suspect it was done just because of poor design
and/or premature optimization.

on the factual side: 

1. the GUILE ends up with 1506 srcprops objects.

2. this is neglible compared to the 431777 total cells that
are allocated.

3. Due to sharing of the filename cons, memory usage is slightly more
than 4 SCMs per srcprop, down from 6 SCMs (2 for the smob cell, 4 for the
struct) 

I actually think it would be a good idea to generalize from double cells,
to cells containing any number between 3 and 8 SCM values.  This would 
be a better fit with some datatypes, and obviates the procustes
hacking to fit all the information inside some struct.

> It's not obvious to me why it should have done, just moving srcprops
> from a specialized storage to the general cell heap.

Because the code made me cringe. It's pointless to have specialized storage
for srcprops. it only makes the code more obtuse.

I you really want to know, ask Mikael Djurfeldt who added the bits 
in 20 aug 1996.

-- 
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen