Too many calls to INFILEP under FINDFILE

[rmkaplan]

@nbriggs noticed that there were an inordinate number of calls to INFILEP when looking up a font, and @hjellinek also noticed a lot of time is going into INFILEP under FONTEXISTS?.

The problem seems to be at a lower level, in the implementation of FINDFILE. Below is a trace of FINDFILE and INFILEP to look for a nonexistent file in a single directory. There are 5 calls to INFILEP, 2 are make no sense (the filename XXX appears also as a subdirectory) and the other 3 all have the same argument--one call should have been enough. I haven't looked further, but FINDFILE goes to SPELLFILE (even with NSFLG T), which goes to FINDFILE-WITH-EXTENSIONS.

[nbriggs]

(the filename XXX appears also as a subdirectory)

Back in 2022, you added this comment to SPELLFILE:

(* ;; "This does the FOO to FOO>FOO correction, with only directory scanning and no other transformations.")

[rmkaplan]

Yes, that's the problem: We wanted to group all the Sketch, Tedit, Lafite, Tmax... files together in their individual subdirectories with a consistent naming convention (SKETCH-OPS, TEDIT-STREAM...), so that a search for SKETCH-OPS would also look for SKETCH>SKETCHOPS, parsing at the first (I think) hyphen. And then we also put main files down inside the same directory, to be in the group, so that the file SKETCH would be SKETCH>SKETCH. So, any lookup that failed for a file FOO without a hyphen would look for FOO>FOO, and any lookup that failed for FOO-FIE would then look for FOO>FOO-FIE. The double lookup isn't so bad (it's typically only the entry-point file (TEDIT, SKETCH) that has a double lookup, the hyphen names for all the subfiles are built-in the FILES commands. But this is compounded for fonts, because of the unrelated convention that the fields of a fontfile name are also separated by hyphens. We could do a little reworking (e.g. put SKETCH at the top-level with all of its subfiles in a parallel directory SKETCHFILES>) and maybe change the subfile convention to use characters other than hyphens so that fonts don't fall into this. Perhaps we should avoid using this generic code when looking up fontfiles, do our own simple loop to go through the font directories. Or we could go the other way, group all the fonts in the same family into a subdirectory (all helvetica medleyfont files in the same place), and let the general mechanism find them. But for starters, the code that's doing all these lookups should be fixed so that it remembers what strings it has already looked up and doesn't look them up again, as the trace showed.

…

On Dec 3, 2025, at 7:07 PM, Nick Briggs ***@***.***> wrote: nbriggs left a comment (Interlisp/medley#2404) <#2404 (comment)> (the filename XXX appears also as a subdirectory) Back in 2022, you added this comment to SPELLFILE: (* ;; "This does the FOO to FOO>FOO correction, with only directory scanning and no other transformations.") — Reply to this email directly, view it on GitHub <#2404 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJNRW4T2JQAZDTRPMWL376QOVAVCNFSM6AAAAACN7R2SD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBZHA2DENZYHA>. You are receiving this because you authored the thread.