[cl-typesetting-devel] Hyphenation config

[Marc Battyani]

"Klaus Weidner" <kw at w-m-p.com> wrote:

> Surprisingly CLISP seems to be *faster* than the native compilers -
> probably because the simpler non-optimizing byte code compiler can eval
> the huge typesetting term more easily.

Probably. When optimizing it will probably be useful to parse the
typesetting document with a special reader and relying on the Lisp
reader/evaluator when there is read code.

> One area that I think is a source of inefficiency is the style handling -
> each style change is handled by a large number of individual assignments
> and conditionals based on the style object for the various property
> variables. I think it would be faster to have a single object (class or
> structure) represent the entire current style, and support reuse of style
> objects rather than creating new ones all the time.
>
> For example, the higher-level code could create one style object each for
> every style combination it needs, and then each style change would be one
> unconditional assignment. The lookup of styles would be a bit slower,
> i.e. a (style-font-size style) indirect lookup instead of directly using
> *font-size*, but I think on balance it would be a lot faster.
>
> This would be most efficient for completely specified style objects (with
> no NULL fields). Handling incompletely filled style objects could still
> be supported via a stack of graphics contents.

Yes this point (text styles) have been discussed earlier. I think it would
be better to store the text-styles stack in a *style-stack* special variable
rather than distributed in lots of separate variables. Or maybe a mixed
system with a few specials for heavilly used styles like *font*.

> It may be faster to implement the low-level style objects as structures
> rather than classes for efficiency, once the format is fixed. Something
> for benchmarking...

At least on Lispworks and maybe ACL this will not give a big improvement
IMO.
Anyway optimisation should be done later. For now there are more urgent
problems like the table colum sizes. ;-)

Marc