[OS X TeX] benchmark a pdflatexmk run on a Mac Studio?

[Herbert Schulz]

> On May 2, 2022, at 3:16 PM, Murray Eisenberg <murrayeisenberg at gmail.com> wrote:
> 
> 
> 
>> On 2 May2022, at 3:27 PM, Doug McKenna <doug at mathemaesthetics.com> wrote:
>> 
>> Here are some data points from my world:
>> 
>> A CPU-intensive, enumeration program that I wrote finds all the Hamiltonian path solutions on an N x N grid-graph that comport with a given a set of constraints.  The backtracking code is single-threaded, and there's no file I/O other than occasional progress messages to the terminal.  On my circa 2015 MacBook Pro Intel, a run takes around 5 hours to find all 20 million solutions for N=11.  On my new M1 MacBook Pro, the run takes a little more than half that time.  So a big win, comporting with various benchmarks saying that M1s represented a 70% increase in speed.
>> 
>> I've got a 32-page math paper with 54 PDF illustrations.  It typesets in TexShop 4.7 on my M1 MacBook Pro in about 1 second to an 8.3MB PDF file.  On my circa-2015 Intel MacBook Pro, using TexShop 4.69, it takes I'm guessing like 1.3 seconds.  This is based on hitting Cmd-T simultaneously on both laptops sitting next to each other and viewing with my own eyes which Console window finishes first.  It's always the M1 Mac, and noticeably so, but certainly not 70% faster.
>> 
>> Because iOS apps can run natively on M1 Macs, I recompiled my 160-page iOS eBook/app for iPads so as to be available in the MacOS app store for M1 Macs.  The eBook/app relies on my own homebrew TeX language interpreter in it (JSBox, written in C), also recompiled.  Each time the eBook/app launches, it reads the TeX source and self-typesets 160 pages anew, keeping the layout results for every page in memory.  Because of the eBook's subject matter and interactive design, using PDF isn't an option (all the 130+ illustrations are created at read-time in the app by C subroutines when a user reveals a page, not at typesetting time).
>> 
>> The point being that the typesetting job reserves a box for each illustration, but is otherwise pure TeX language and layout computation, without any PDF or DVI or other input/output processing issues for illustrations.  No files are written during the job.  No other TeX infrastructure tools like ghostscript are relied upon.
>> 
>> The internal interpreter records the run time of the typesetting job at each app launch.  For 160 pages (the eBook's virtual pages are long, 8.5" by 18"), the speed of its self-typesetting on my M1 Mac is about 140 milliseconds, whereas the speed on the older Intel machine (same as above) I developed it on is around 400 milliseconds.  One caveat, of course, is that on the Intel machine, the code is translated on the fly by either Rosetta or the iOS device simulators into ARM code (or it's otherwise emulated).  But even with that inefficiency taken into account, I think the TeX interpretation and layout algorithms are significantly faster on the M1 silicon, perhaps getting back towards the 70% level.
>> 
>> Which says to me that whatever is keeping a large pdfLaTeX project from being accomplished much faster on an M1 Mac, it's somewhere other than in the TeX language engine.  There could also be some kind of cache issues that have cropped up, I suppose.
>> 
>> Perhaps the Mac's Activity Monitor program (see Applications/Utilities/) could show what processes might be involved in a time-consuming pdfLaTeX job that takes minutes to accomplish.
>> 
>> Doug McKenna
> 
> Does the following documentation of my multi-file preamble give any clue to the total processing time?
> 
> % Root file LOADS
> %	pdfmanagement-testphase.sty (with \DocumentMetadata{uncompress,pdfstandard=a-2u}),
> %     snapshot.sty,	
> %	longnamefilelist.sty,
> %	iftex.sty, ifthen.sty,
> %     nag.sty
> %	preamble/mypackages.sty, 
> %	preamble/myfonts.sty, preamble/mymath.sty,
> %	preamble/mygraphics.sty, preamble/mystyle.sty, 
> %	preamble/mythms.sty, preamble/lists.sty, preamble/topdefs.sty, 
> %	preamble/links.sty, preamble/labels.sty
> %
> % Package mypackages.sty LOADS
> %	xstring.sty, suffix.sty,
> %	calc.sty, etoolbox.sty, xpatch.sty, 
> %	adjustbox.sty, scalerel.sty,
> %	moresize.sty, csquotes.sty, multicol.sty,
> %	textcase.sty, stackengine.sty, mfirstuc.sty, embrac.sty
> %	enumitem.sty,
> %	longtable.sty, makecell.sty,
> %	blindtext.sty
> %
> % Package myfonts.sty LOADS
> %	fontenc.sty,
> %	amsmath.sty, mathtools.sty, amsthm.sty,
> %	iftex.sty,
> %	babel.sty, substitutefont.sty, 
> %	fonts: Tempora-TLF,
> %           newtxtext.sty, newtxmath.sty
> %	  ... pifont.sty, cmap.sty.,        
> %	graphicx.sty,
> %	microtype.sty
> %
> % Package mymath.sty LOADS
> %	xfrac.sty, nicefrac.sty,
> %	mismath.sty, mathfixs.sty,
> %	derivative.sty, mleftright.sty, centernot.sty, 
> %	interval.sty
> %
> % Package mygraphics.sty LOADS
> %	graphicx.sty,
> %	tcolorbox.sty,
> %	pict2e.sty, tikz-cd.sty
> %
> % Package mystyle.sty loads nothing
> %
> % Package mythms.sty LOADS 
> %	empheq.sty, thmtools.sty
> %
> % Package mylists.sty LOADS
> %	eqparbox.sty
> %
> % Package topdefs.sty loads nothing
> %
> % Package links.sty LOADS 
> %	biblatex.sty, nomencl.sty,
> %	xurl.sty,
> %	doclicense.sty, hyperxmp.sty
> %	hyperref.sty 
> %	xassoccnt.sty, zref.sty
> %	cleveref.sty, crossreftools.sty,
> %	orcidlink.sty,
> %	etoc.sty
> %
> % Package labels.sty LOADS
> %	showkeys.sty,
> %	fixme.sty,
> %	mindflow.sty
> 
> ---
> Murray Eisenberg		murrayeisenberg at gmail.com
> Mobile (413)-427-5334
> 503 King Farm Blvd #101		
> Rockville, MD 20850-6667	

Howdy,

It is possible to pre-compile the preamble and load that instead of re-reading all the packages each time. Of course that's only useful if that is fairly static.

I'll leave it to someone else to describe how to do that dump and then use it.

Good Luck,

Herb Schulz
herbs at wideopenwest.com