Neil Jerram escreveu: > Kevin Ryde <[EMAIL PROTECTED]> writes: > >> Han-Wen Nienhuys <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
