On Sunday 21 July 2002 06:46 pm, Scott Walters wrote: > 2. PMCs return iterators allocated on a stack that allow them to function > as KEY *s allocating a single fixed size peice of memory rather than all of > the parts of a linked list. In other words, factor out the part of PMCs > that index a given element. This would completely bypass the construction > of KEY* lists, and allow PMCs to function as keys. This case needs to be > optimised, as most keys will be scalars or a few scalars, and quickly > moving from a scalar to a key should be paramount. > 3. Let PMCs create KEY * lists. Whats more, rather than scraping KEY * > lists of an adequate size and replacing them every iteration in user > code loops, *update* the KEY* list from PMCs. Eg, if $x is the first item, > $y is the second, and $z is the third, update the values in the KEY* with > the new values from the scalars, then shuffle the same KEY * off again. Use > a load/store strategy! The complexity involved in exposing every single > method in a contained object damages cache use beyond *any* possible > benefit! See earlier post for details.
Not to beat a dead horse, but I like the concept. However, rather than using the KEY* linked list, use a tuple. They would be constant size, so we could allocate them on the stack. They would iterate nicely without thrashing memory. No malloc(), so we could keep the main KEY* functionality without adding a special-purpose key pmc, and we'd get a *fast* generic Tuple PMC class out of it. Ashley (by committee) Winters -- When you do the community's rewrite, try to remember most of us are idiots.
