Re: freeing srcprops ?

[Mikael Djurfeldt]

2007/1/29, Han-Wen Nienhuys <address@hidden>:
> 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.

While I have to admit that I was a novice programmer at the time I
wrote this code, and definitely didn't have enough experience to judge
what is a good design, I fail to see what is so bad about that code.
Also, please remember that things looked quite differently then.  For
example, there were no double cells.

Neil is quite right about the reasons for doing it like that.  As you
know, computers were at that time a lot slower.  Also, Guile, and
especially SCM which Guile was derived from, was far more "efficient",
so that small code changes wasn't drowned but had a noticeable impact.
I would say the idea of storing a lot of information for every
s-expression in the code was at that time a bit outrageous, so I saw
it as very important to prove that this concept was in fact realistic.
So I made sure that allocation size and time was optimized.  Another
aspect is that the breakpoint flag needed quick access in order to
test if such a scheme could be used for breakpoints instead of code
substitution (which might still be a better idea).

> on the factual side:
>
> 1. the GUILE ends up with 1506 srcprops objects.

Source properties have work also for large projects, so it's that kind
of situation we need to look at.  I think my own projects have reached
20000 objects or more.

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

Yes, it could very well be the case that an extra effort is poorly
motivated by memory usage alone.

> 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)

Hmm...  Your filename optimization doesn't really work, does it?  As
soon as someone sets a breakpoint, he gets it all over the place, or
did I miss something?

If I'm right, the 1996 "solution" was, at least, down to 6 SCM from 8
(since we didn't have double cells, while your solution is in fact
4+4=8.  But you could probably easily get it down to 6---not that it
matters much now.

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

If we considered implementing source properties *now*, I would
probably agree.  But the code is already there and I wonder if there
really is any gain of replacing it.  For example, the code you need to
add in order to do the filename optimization is hardly much more
maintainable than what we already had in there, and it is my guess
that whatever alternative code you propose, it won't be faster or
consume less memory.

Also, Neil should probably study the effects on his debugging code of
putting the breakpoint flag in the standard property list.  What
happens if the property list is used for other things so that it has
to be traversed for, for example, one step?

I guess you active guys should sort this out between yourselves.

Thanks for working on Guile,

Best regards,
M