On Sun, Sep 6, 2009 at 9:25 PM, Edward K. Ream <[email protected]> wrote:
> > Actually, I can be even more emphatic about this statement. > > It is not immediately obvious from the code, but it is a fact nonetheless, > that Leo's present iterators are already highly optimized. A loop such as: > > for p in c.allNodes_iter(): > << whatever >> > > generates *exactly one* position p, and this position is "moved" by the > iterator using p.moveToX methods. This is a crucial space optimization. The Yeah, a space optimization. I'm thinking of time optimization here. > comment in the p.moveToX node says: > > QQQ > These routines change self to a new position "in place". > That is, these methods must _never_ call p.copy(). > QQQ > > Furthermore, p.stack turns out to be essential in computing the next > position. To contemplate "optimized" vnode iterators is misguided: they > would have to simulate p.stack in order to work properly. I'm thinking of using a recursive generator for this. OTOH, emulating the position stack is easy. Don't bother too much about this yet, just implement the straightforward version in terms of positions as you suggested and I'll provide & benchmark the optimized version later. My gut feeling tells me significant speedup can be achieved, but of course I might be wrong. This is a harmless optimization in that no changes outside of this function will be needed. -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
