MULE rant...

David Kastrup dak at gnu.org
Tue Aug 31 10:15:06 EDT 2004


"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> >>>>> "David" == David Kastrup <dak at gnu.org> writes:
> 
>     David> It might be what I have to do in the end, but it certainly
>     David> does not sound like a recipe for performance.
> 
> It's not a recipe for performance if you need to do it more than
> 100000 times per second.  Do you?  Or are you training in hopes of
> taking the gold medal in the 1000000 decodings event in Beijing?

It is by far the slowest part in the blocking portion of
preview-latex.  It is the part that our users complain about.  It is
the part where preview-latex created a special streamlined
high-performance interface to X-Symbol because the users complained
about the combination starting to impede their work.

This operation will be called at least 4 times for every snippet in
the text (two pieces of context for beginning and end of snippet,
respectively) if I manage to do the partly-converted character stuff
with a different trick and need only deal with the incomplete
character mess, and a typical preview-latex document contains several
thousands of those.  If a usual computer is blocked for 10 seconds
while parsing those, this is a nuisance of high degree.  We have in
the order of several man-months of development in that area because it
was a central point of user complaints.

You might find it very funny, but I assure you that performance in
that particular part of the code is very highly correlated to
usability.

Yes, I don't want to waste performance where it hurts, hard.  It might
be possible to come up with a scheme that is hardly impacted by that
problem, I don't know yet.  Maybe I can find some workaround code for
XEmacs that is specific to utf-8 (and would thus fail with Japanese
text encodings, for example).

I don't really enjoy the thought of having utf-8 specific backends for
cleaning up incomplete characters and stuff, and Japanese backends and
whatever.

And I don't enjoy the thought of keeping the whole output stored
somewhere in raw byte form.

We'll have to see what kind of solution is possible.  I might also
just choose to say "not supported on XEmacs, volunteers welcome".
Probably the sanest choice.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




More information about the XEmacs-Beta mailing list