ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <j.hagen@xs4all.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>,
	Taco Hoekwater <taco@elvenkind.com>
Subject: Re: Using ConTeXt-LMTX for modern Mathematically-Literate-Programming 1/2
Date: Thu, 3 Dec 2020 13:15:28 +0100	[thread overview]
Message-ID: <96839230-443e-3829-4d9a-574df16cafbe@xs4all.nl> (raw)
In-Reply-To: <42ADA9D0-2CE2-4FD6-B245-8C6F8AF2CF11@elvenkind.com>

On 12/3/2020 12:15 PM, Taco Hoekwater wrote:
> 
> 
>> On 3 Dec 2020, at 11:35, Stephen Gaito <stephen@perceptisys.co.uk> 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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

  reply	other threads:[~2020-12-03 12:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30  9:51 Stephen Gaito
2020-11-30 18:59 ` Hans Hagen
2020-12-02  9:40   ` Stephen Gaito
2020-12-02 13:04     ` Hans Hagen
2020-12-03 10:35       ` Stephen Gaito
2020-12-03 11:15         ` Taco Hoekwater
2020-12-03 12:15           ` Hans Hagen [this message]
2020-12-03 17:08             ` Stephen Gaito
2020-12-03 16:53           ` Stephen Gaito

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=96839230-443e-3829-4d9a-574df16cafbe@xs4all.nl \
    --to=j.hagen@xs4all.nl \
    --cc=ntg-context@ntg.nl \
    --cc=taco@elvenkind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).