Neil Jerram escreveu: >>>>> 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. > > Except you haven't given any objective reasons for why the design is > poor or the optimization premature.
Any deviation from the standard memory allocation scheme should have a good reason, or -at least- a documented reason. This design predates several revisions of the garbage collector, so I suspect that whatever reason there was for this idea, is no longer valid. >> on the factual side: >> >> 1. the GUILE ends up with 1506 srcprops objects. > > Out of interest, in what scenario? Startup (with --debug), which you brought up earlier. As I indicated in an earlier message, I did not see any measurable change in startup time. >> 2. this is neglible compared to the 431777 total cells that >> are allocated. > > (Which suggests to me that the decrease in memory from your change > wasn't that worthwhile.) That was not the point of the change. >> 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. > > Maybe. I think this would have to be motivated by looking at > particular cases where we get benefits from moving struct data into a > multiple cell. I don't think the srcprops case is clearcut > (obviously), and I don't see anything wrong with the general approach > of indirecting to a struct. I don't mind either, but since the old code was using a struct with its own 'optimized' memory management scheme, I assumed that an even better scheme (due to lower memory use) could not be questioned. >> Because the code made me cringe. It's pointless to have specialized storage >> for srcprops. it only makes the code more obtuse. > > I disagree. I believe Can we have some measurable data? Thanks, -- 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
