On Mon, Jan 14, 2008 at 12:47:35AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > I am currently poking around in the code and got the feeling that our
> > iterators have a tendency of being used wrongly, possibly because parts
> > are not really well implemented, and possibly because we don't have
> > explanations on what to use when.
> >
> > The result was e.g. a 20% runtime increase when loading the UserGuide.
>
> Wow, could you give more details? Is this because of iterator copies?
The macro update thing did a full document traversal by using
ParIterator::forwardPos().
Now, operator==() for ParIterators copy-constructed DocIterators to call
operator==() on them. That's half of it or so.
The other half stems from the fact that checking each DocIterator
position for pointing to an inset instead of using (a still non-existent)
some means to iterate over insets only is not particularily fast,
either.
> > I am tempted to collapse all the iterator classes into one (or two, for
> > a const variant) 'DocIterator'. It's pretty much what we have now,
>
> If you implement DocConstIterator I can forgive you the rest ;-)
>
> > except the question 'which one to use' would not arise, and
> > 'operator++()' wouldn't do 'the right thing'. I don't think that's a
> > major obstacle as e.g. ParIterator does have somewhat strange semantics
> > anyway.
> >
> > Comments?
>
> Dunno, I always thought that {Inset,Par}Iterator could be used just
> as 'proxy' classes in order to have iterator semantics for a specific
> purpose (e.g. use some generic algorithm). But I don't really know if this
> is just my imagination or the real use in the code nowadays... Your patch
> will tell I guess ;-)
That was the idea, but it was never fully implemented nor ready for use
by the innocent... Just Doc{Const,}Iterator with appropriate
forwardFoo() functions will probably less likely create non-obvious
trouble,
Andre'
