LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Hans Aberg <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Wed, 1 Jul 1998 18:55:11 +0200
text/plain (60 lines)
At 17:00 +0100 98/07/01, Robin Fairbairns wrote:
>>   To give the optimizer another name than docstrip then, so it may be used
>> at will.
>the name of the program doesn't affect its speed at all (though i
>suppose if you painted go-faster stripes down the side...)

  Well, if you give the optimizing facility another name than docstrip,
people need not using it when using the docstrip facility, so in that case,
the docstrip facility is not going to run slower. :-)

>*why* do we need this?  executing the \newcommand does indeed
>ultimately lead to execution of a \def statement, as you suppose.  and
>the \newcommand is slightly slower to execute than is the \def on its
>own, but so what?  that command is only going to be executed once in a
>tex run, after which the (tokenised) command definition is hashed away
>somewhere and is executed as fast as one can hope.

  Well, I think I said the best way to find out which commands to optimize
is to use a profiler, and in other cases I use examples to illustrate the

  Otherwise, even though \newcommand is only executed once for every
command created, one might guess that \newcommand itself is executed many

>i don't think an optimiser that operates on classes and packages helps
>much, and i don't believe an optimiser that works on documents is

  So what is making LaTeX so slow then?

>it seems you're saying "we need to program these things before we've
>got a coherent idea of how to name them".  this way (to my mind) leads
>to madness, which was why i was re-reading the standard texts on naming.

  I think that the point that has been repeated many times over and over
again is that module separators and word separators should be distinct if
one would want to prepare for the use of submodules.

  What I had in my mind though was developing the concept of modules into
both an abstraction and a programming technique in TeX with its limited
capacity for such things. All I can say that I found it difficult to do
that from the limited programming I did, and my conclusion was that this
was the way to go.

>>   By the way, I put up a doc, "modules/ModuleConventions.txt", on my home
>> page, with contains some of the ideas I had that might be used to define
>> modules.
>you quote two home pages, but afaict this file isn't in either of them
>(i tried conventional html suffixes too).

  Hans Aberg
                  * Email: Hans Aberg <mailto:[log in to unmask]>
                  * Home Page: <>
                  * AMS member listing: <>