On Thu, 2 May 2024 14:47:41 -0600 Karl Berry <k...@freefriends.org> wrote: > it looks like the LuaTeX binaries were compiled with "-g -O2", but > running "readelf" and "objdump" shows that they're stripped, so I > don't think that that's the issue here. > > FWIW, it's my understanding that what matters for execution speed is not > the presence or absence of debug symbols (-g), but whether optimization > was enabled (-O2 or similar). > > Debian Sid arm64 LuaTeX: 0m15.392s > Debian Sid arm64 pdfTeX: 0m7.914s > TeX Live 2023 arm64 LuaTeX: 0m0.737s > TeX Live 2023 x86_64 pdfTeX: 0m0.156s > TeX Live 2023 x86_64 LuaTeX: 0m0.156s > > Not sure whether to conclude it's arm-specific or sid-specific or both > from those numbers, but I suppose a few more runs would show. > >From my testing, it seems specific to arm64 under qemu. armhf/armel do not seem to have the same load times at all. >From digging through our build server, the change occurred in Debian testing sometime between the 15th and the 30th of November. I have the list of the 1122 packages that were changed in that time, and have been slowing working through it to weed out the packages that definitely couldn't cause the issue (not installed/won't be installed), but it's slower going than I would like. There is definitely another performance regression, but none seem as severe as this one which in our builds adds almost 3 hours to the time.
> LuaTeX 2024 could be getting slowed down a bit by the additional access > checking, I suppose, but there were no significant changes in pdfteX in > 2024, so that can't be the whole explanation. > > FWIW, building lualatex.fmt on my x86_64-linux (Rocky Linux 9.3) home > machine, with the TL luahbtex binary, took about six seconds. > Rebuilding all the formats took about 80 seconds, last time it happened. > > Best, > Karl > Unfortunately, I'm not at all experienced with LaTeX, and we're only pulling the dependency in by happistance of something else depending on it to generate pdf reports. The main reason I suspected it is that, according to the packaging changelog, arm64 enabled lua support in the above timeframe. As Max pointed out, sid is now much slower than stable, so it could be something completely different is causing this to manifest. --steev
