\input gets slower after each \input

barbara beeton bnb at tug.org
Tue Apr 27 19:25:44 CEST 2021


On Tue, 27 Apr 2021, Phelype Oleinik wrote:
> On 27/04/2021 12:34, barbara beeton wrote:
>>
>>  This has come up before, although with situations involving different
>>  input file names, not the same name as in the present test.  When a
>>  file access is completed (definitively closed), ur-TeX would attempt
>>  to remove the name from the string pool.  But if anything else had
>>  been added to the string pool, the name was not removed, since the
>>  complications of garbage collection outweighed the space saving.  I
>>  don't think that approach has changed
>
> It doesn't seem to have been changed, because as Ulrike noted, the
> example eventually explodes with a string pool overflow, and all it
> does is to input the same file over and over again.
>
> However the access time for string memory is constant, since it is just
> a pointer to a large array.  In fact, the sample takes roughly the same
> time to run regardless if the file is |abcdefghijklmnopqrstuvwxyz.tex|
> or just |a.tex|, which indicates that it is not _how much_ string memory
> is used, but how many strings are added to the pool.
>
> My questioning is if the space saved by reusing some chunks of the
> string pool is worth the time taken to search through it...

It certainly wasn't worth it when memory was at a premium; any space
saved would have been (more than) consumed by the code necessary to
accomplish it.

> Speaking of which: if a string is reused when found in the pool, why
> does the example runs out of string space?  Shouldn't it reuse always
> the same string?

It's been literally decades since the limitation was discovered at AMS,
and even if the explanatory correspondence has survived, I no longer
have access to it, and am not up to digging through the WEB code.
 						-- bb

> Phelype


More information about the tex-live mailing list.