ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Wolfgang Schuster via ntg-context <ntg-context@ntg.nl>
To: Rik Kabel <ConTeXt@rik.users.panix.com>
Cc: Wolfgang Schuster <wolfgang.schuster.lists@gmail.com>,
	mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: directsetup vs setups
Date: Mon, 15 Nov 2021 23:48:16 +0100	[thread overview]
Message-ID: <579cc968-4bfd-8024-7c41-117318f79f00@gmail.com> (raw)
In-Reply-To: <c4306f2b-3555-cb6f-787b-fafb98fe2c79@rik.users.panix.com>


[-- Attachment #1.1: Type: text/plain, Size: 3333 bytes --]



Rik Kabel schrieb am 15.11.2021 um 22:51:
>
> Wolfgang,
>
> Can you expand on the following statements from your reply?
>
>     You can run Hans example with MkIV and the differences should be
>     even bigger because the check for [] is slower here while in LMTX
>     it's a engine feature. The main difference in LMTX is a extra
>     expansion for \setup compared to \directsetup.
>
>     there is no difference between \setup and \directsetup
>
> Are you saying:
>
> 1. When [] are used with \setup, expansion of the contents is done 
> differently than when {} are used.

It doesn't matter which form you use for \setup.

What I'm trying to say is that \setup is slower (or better was slower in 
MkIV) than \directsetup because \setup has to check first if the name is 
passed within brackets or as normal argument in braces.

The code in MkIV would look similar to this:

\def\setup
   {\doifnextcharelse[
      \setup_brackets
      \setup_braces}

\def\setup_brackets[#1]%
   {\directsetup{#1}}

\def\setup_braces#1%
   {\directsetup{#1}}

> 2. There is no significant processing time difference between \setup 
> and \directsetup.
>

When I run the following example on my machine

\starttext

\startsetups [dummy]
\stopsetups

\testfeatureonce{100000}{\setup      {test}} \elapsedtime \par
\testfeatureonce{100000}{\directsetup{test}} \elapsedtime \par

\stoptext

I get these times.

# MkIV

\setup       : 0.136s
\directsetup : 0.079s

# LMTX

\setup       : 0.083 seconds
\directsetup : 0.071 seconds

Add additional stuff in the setup environment and the difference between 
\setup and \directsetup doesn't matter anymore.

> 3. There is additional expansion performed for \setup compared to 
> \directsetup.
>

Although this isn't completely true (but very close) the definition for 
\setup in LMTX is like this:

\def\setup#1{\directsetup{#1}}

> 4. Under LMTX, because {} and [] handling overhead is so similar, the 
> most visible processing time difference to users is from the 
> difference in  expansion between \setup and \directsetup.
>
> I think you are saying that 2, 3, and 4 are true, but that 1 is not true.
>
> If that is the case, can you provide an example that demonstrates the 
> difference in expansion between \setup and \directsetup?
>
> Also, as far as expansion, is \fastsetup like \setup or like \directsetup?
>

\setup and \directsetup are similar. \fastsetup is like the name implies 
a faster version which ignores grid mode and doesn't care whether the 
requested environment even exists.

> My simple testing shows no difference between setup, directsetup, and 
> fastsetup for namespace set and reset. Is it your understanding that 
> they all behave the same?
>

No, \fastsetup behaves different because it leaves \relax\empty in the 
input when you pass the name of a not existing environment.

It shouldn't matter in normal usage but below are two examples.


Example 1:

\starttext

\tex{directsetup}

\scratchcounter 12\directsetup{unknown_a}34

\the\scratchcounter

\tex{fastsetup}

\scratchcounter 12\fastsetup{unknown_b}34

\the\scratchcounter

\stoptext


Example 2:

\starttext

\normalexpanded{\noexpand\firstoftwoarguments\directsetup{unknown_a}xy}

\normalexpanded{\noexpand\firstoftwoarguments\fastsetup{unknown_b}xy}

\stoptext


Wolfgang


[-- Attachment #1.2: Type: text/html, Size: 4800 bytes --]

[-- Attachment #2: Type: text/plain, Size: 493 bytes --]

___________________________________________________________________________________
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
___________________________________________________________________________________

  parent reply	other threads:[~2021-11-15 22:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15  5:24 Rik Kabel via ntg-context
2021-11-15  8:21 ` Denis Maier via ntg-context
2021-11-15  9:38 ` Hans Hagen via ntg-context
2021-11-15 18:06   ` Rik Kabel via ntg-context
2021-11-15 18:54     ` Wolfgang Schuster via ntg-context
     [not found]       ` <c4306f2b-3555-cb6f-787b-fafb98fe2c79@rik.users.panix.com>
2021-11-15 22:48         ` Wolfgang Schuster via ntg-context [this message]
2021-11-15 21:33     ` Hans Hagen via ntg-context

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=579cc968-4bfd-8024-7c41-117318f79f00@gmail.com \
    --to=ntg-context@ntg.nl \
    --cc=ConTeXt@rik.users.panix.com \
    --cc=wolfgang.schuster.lists@gmail.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).