[tex-live] strange discrepancy in running time of etex between TL2015 and TL2017

[Reinhard Kotucha]

On 2017-07-27 at 08:58:43 +0200, jfbu wrote:

 > Thanks a lot for trying out, the most likely cause is that the 
 > 
 > def\x{3.141592653589793238462....
 > 
 > line got hard-wrapped somehow so that it occupies multiple lines
 > 
 > (it should be on only one line)
 > 
 > and this means the \x has spaces in it and the \ifx test fails
 > because the \Z computed by \fdef\Z {\Machin {1000}} contains
 > the first 1000 digits of Pi with no spaces.

The problem was that the value of \x contained three spurious
characters (numbers are code points):

  0039: DIGIT NINE
  0032: DIGIT TWO
  0037: DIGIT SEVEN
  0038: DIGIT EIGHT
  0037: DIGIT SEVEN
  0021: EXCLAMATION MARK
  000A: <control> LINE FEED (LF)
  0020: SPACE
  0036: DIGIT SIX
  0036: DIGIT SIX
  0031: DIGIT ONE
  0031: DIGIT ONE
  0031: DIGIT ONE

I do not know where these characters had been inserted.  But if you
send code by mail which contains non-ASCII characters and/or where
linebreaks matter, I strongly recommend to send the file as an email
attachment.  It's also advisable to gzip the file because it's marked
as "application/octet-stream" then by your mail client.

You can trust \pdfelapsedtime because it just uses system calls but I
don't know which system call is used by pdftex.  It seems that it's
based on gettimeofday(2).

Luatex provides os.clock() and os.gettimeofday().

os.clock() counts CPU cycles of the current process with a resolution
of 10 ms.  It disregards CPU cycles used by sub-processes or other
processes running at the same time.

os.gettimeofday(), as its name implies, just returns the current time
and is less reliable when a cronjob is running or Emacs creates an
auto-backup.  The resolution is system dependent (1µs on Linux and
500µs on Windows).  Don't be confused by the many decimal digits.
Most of them are just rounding errors which are almost always
introduced when binary numbers are converted to the decimal system.
See also

  https://www.tug.org/TUGboat/tb28-3/tb90beebe.pdf

If you are using \pdfelapsedtime, os.clock(), or os.gettimeofday(), it
doesn't matter whether any files are cached already, at least if your
input file resets the counter at the beginning and you avoid \input.
IMO it's best to use os.clock() on LuaTeX for benchmarks despite its
low resolution.  The problem you reported is OS/X specific but in most
cases a resolution of 10 ms is sufficient on a Raspberry Pi.

If you are using time(1), which depends on gettimeofday(2), you have
to run the script several times because other processes might run in
the background.  It's also advisable to install a system monitor like
xosview.

Regards,
  Reinhard

-- 
------------------------------------------------------------------
Reinhard Kotucha                            Phone: +49-511-3373112
Marschnerstr. 25
D-30167 Hannover                    mailto:reinhard.kotucha at web.de
------------------------------------------------------------------