\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.