Re: [Texmacs-dev] TeXmacs profiling

[Joris van der Hoeven]

On Sat, 22 May 2004, David Allouche wrote:
> On Fri, May 21, 2004 at 10:15:48AM +0200, Joris van der Hoeven wrote:
> > On Fri, 21 May 2004, David Allouche wrote:
> > > Structured sections are no magic bullet. They will not remove the full
> > > retypesetting currently done when the indentation of a paragraph is
> > > changed.
> >
> > When using structured sections, the no/yes-indent-after tags
> > are no longer needed, so they can be removed from the program.
> > In fact, this whole idea is quite dirty alltogether.
> > We will still keep the no/yes-indent-before tags,
> > but these ones are much easier to deal with.
>
> Wrong. Indent-after flags are still needed, at least for disabling
> indentation after blocks structures like lists.

No, we should rather implement the 'para' tag for this.

> > > In addition, they will actually slow things down, since there are
> > > several algorithms which are quadradic in the depth of the document,
> > > involving lots of path reversions. Or did the path-decorated trees
> > > removed that issue?
> >
> > No, but I do not think that they would slow things down, since the depth
> > of the document is usually proportional to the logarithm of its size.
> > In fact, in the present state, using recursive sections will speed-up
> > editing large documents by a huge amount, because it avoids the presence
> > of 'document' tags with many children. You may check that yourself by
> > selecting the structured-section package.
>
> If I recall correctly, the "big top-level document tag" is one of the
> things that suck a lot of computation, because when a node is modified,
> all the bridges of the ancestor nodes, and the right siblings of those
> ancestor nodes, are notified of the change.

I suspect that the real penalty comes from the shoving algorithm.
The notifications should be inexpensive, because they are essentially
no-ops (even though there are many of them).

> That particular performance issue can be solved by the lazy typesetting
> and balanced tree mechanism you plan to implement, so there is no need
> to incur the performance penalty of deeper documents.

In fact, we should have both. In any case, adding one or two levels
of depth (section, subsection) will not profoundly alter the efficiency
(except for the source-tree mode, where things are not yet lazy enough).

I am really quite sure that recursive sections will change virtually
nothing from the performance point of view. Again, with the present
implementation of bridges, they will actually be much faster.