Re: [NTG-context] Using ConTeXt-LMTX for modern Mathematically-Literate-Programming 1/2

On 12/3/2020 12:15 PM, Taco Hoekwater wrote:

...

On 3 Dec 2020, at 11:35, Stephen Gaito wrote:

Hans,

As I said my desktop is elderly... it has a 2.8GHz processor, 16Gb of DDR3 memory, and a couple of old SATA1 hard disks, and only 3Mb of CPU cache...

... all well past its use by date for single threaded ConTeXt. ;-(

So one way to get better performance for ConTeXt is to invest in a new ultra fast processor. Which will cost a lot, and use a lot of power which has to be cooled, which uses even more power....

Startup time can be improved quite a bit with an SSD. Even a cheap SATA SSD is already much faster than a traditional harddisk. Doesn’t help with longer documents, but it could be a fairly cheap upgrade.

also, an empty context run \starttext \stoptext only takes 0.490 seconds on my machine, which means: - starting mtxrun, which includes quite a bit of lua plus loading the file database etc - loading mtx-context that itself does some checking - and then launches the engine (it could be intgerated but then we run into issues when we have fatal errors as well as initializations so in the end it doesn't pay off at all) - the tex runs means: loading the format and initializing hundreds of lua scripts including all kind of unicode related stuff so, the .5 sec is quite acceptable to me and i knwo that when i would have amore recent machine it would go down to half of that now, making a tex run persistent is not really a solution: one has to reset all kinds of counters, dimensions etc wipe node and token space, etc an done would also have to reset the pdf output which includes all kind of housekeeping states ... adding all kind of resetters and hooks for that (plus all the garbage collection needed) will never pay back and a 'wipe all and reload' is way more efficient then of course, when i ever run into a secenario where I have to creeate tens of thousands of one/few page docs very fast i might add some 'reset the pdf state' because that is kind of doable with some extra code but to be honest, no one ever came up with a project that had any real demands on the engine that could not be met (the fact that tex is a good solution for rendering doesn't mean that there is demand for it ... it is seldom on the radar of those who deal with that, who then often prefer some pdf library, also because quality doesn't really matter) these kind of performance things are demand driven (read: i need a pretty good reason to spend time on it)

I can’t comment on how to speed up the rest of what you are doing, but generally multi-threading TeX typesetting jobs is so hard as to be impossible in practise. About the only step that can be split off is the generation of the PDF, and even there the possible gain is quite small (as you noticed already).

indeed, see above

Typesetting is a compilation job, so the two main ways to speed things along are

1) split the source into independent tasks, like in a code compiler that splits code over separate .c / .cpp / .m / .p etc. files, and then combine the results (using e.g. mutool)

2) precompile recurring stuff (in TeX, that would mean embedding separately generated pdfs or images) right

(and we are old enough and have been around long enough to have some gut feeling about that) Hans ps. When it comes to performance of tex, lua, context etc it is no problem, when googling a bit, to run into 'nonsense' arguments of why something is slow ... so don't take it for granted, just ask here on this list ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------