[tex-live] kpathsea performance

Patrick Davey patrick.davey at gmail.com
Sat Aug 25 02:32:56 CEST 2018

On Sat, 25 Aug 2018 at 09:42 Karl Berry karl at freefriends.org
<http://mailto:karl@freefriends.org> wrote:

Hi Patrick,
>     \centertext{\figure{FILENAME.broken.PNG}}}
> If the reference is broken, yes, it will take time to search the disk
> for casefolded matches (and fail). There is no way around that. That is
> the point of the feature.
Right fair enough :) It’s just that it was 0.2 secs vs 7.8 seconds (which
is a decent difference). I get that casefolded matches are going to take
more time, and it’s totally fine that it’s the default now, it just took me
us by surprise and took a while to work out what the fix was.

> But in your real document, presumably there are no broken references.
> Does casefolding or not still make a difference? I would expect not.
> When references resolve (with no casefolding necessary), it should not
> matter whether it is on or not.
It absolutely makes a difference, sorry for not being clear. Creating a
sample doc takes 16.8 seconds case insensitive vs 1.5s case sensitive. In
that doc there are no .fmt extensions (we do use .FIG and .AUX, I’m not
sure if those are our custom includes or not).

What might be interesting (and it makes sense), we have 3 directories that
we pass to tex to search through i.e. texinputs=dir1;dir2;dir3. In our case
most of the files were actually in dir3 in the 16.8 second doc above. So, I
moved the include order around so that dir3 was first, and the time (with
case insensitive searching) fell to 3 seconds. Now, in our use case, we
have many thousands of files in these directories, so, perhaps we’re an
unusual case.

I’m not sure if there’s anything “broken” per se, but, it’s definitely a
large drop in performance.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20180825/26b5659c/attachment-0001.html>

More information about the tex-live mailing list