IMO the file search performance can be improved, in detail for files to compile.

Currently FileExists is called for every possible directory, name case and possible extensions. This means that the OS may have to search the same directory multiple times, for all these cases - O(n). This can be reduced to one search, when the (possible) filenames are matched in one FindFirst/FindNext run - O(1).

For compiler purposes we IMO can assume that only the file extension can be unknown (.pp, .pas...), so that wildcard handling can be reduced to an match of the name, followed by an match with the list of possible extensions.

Further optimizations can be applied to specialized FindFirst/FindNext implementations, by dropping everything not related to filename matching (get file attributes, file times...).

Has something like this already been tested? I've seen that compiler directory caching is disabled - for what reason?

I'll try to implement and test the simple case (case insensitive Windows filesystems). The procedures for case sensitive filesystems will be a bit harder to implement, of course.

Any comments are welcome :-)

DoDi

Hans-Peter Diettrich wrote

I've seen that compiler directory caching is disabled - for what reason?

It's not disabled, except if you disable it yourself via the -Fd command line option.

Jonas

> I've seen that compiler directory caching is disabled - for what reason? It's not disabled, except if you disable it yourself via the -Fd command line option.

You're right, perhaps I've been fooled once more by the Lazarus code tools. It looks like nobody ever used Lazarus to work on the compiler sources. But all encountered bugs have been fixed promptly :-)

DoDi