I studied the compiler internals by debugging it.

Does TViHashList have any documentation or diagram or anything? It differs from many other hash maps. Is it based on some other code which is documented?

TFPHashObjectList is based on it. It is used for all symbols but also for predefined directives. How about setting its capacity initially in such cases, like:

      procedure InitScanner;
        begin
          turbo_scannerdirectives:=TFPHashObjectList.Create;
+        turbo_scannerdirectives.Capacity:=150;

Less GetMem() calls, copying data and recalculating hashes.

For predefined directives and tokens a "perfect hash" would be perfect. :)  I mentioned it in this MR

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/126

Juha

I made it in
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/132.

It’s a synthesis of the old TFPHashList (from which it inherited O(N) removals), and my private bleeding-edge hash table based on the Python 3.6+ dict:
https://github.com/zpoint/CPython-Internals/blob/master/BasicObject/dict/dict.md.

Such things are not something you should worry about, and they don’t concern the compiler’s logic — treat it as a black box.

runewalsh via fpc-devel kirjoitti 21.9.2026 klo 16.20:

Thanks for the information!

I understood it reduces memory consumption a lot which should also improve speed indirectly in most computers (less memory traffic). Then if AnsiStrings are used for symbol, it slows down the compilation because of try..finally blocks. Is it so?

Such things are not something you should worry about, and they don’t concern the compiler’s logic — treat it as a black box.

No, I want to understand everything. :)

I got obsessed with the perfect hash thing for quickly finding language tokens and directives. I didn't figure out the gperf usage so I made some code of my own. I may experiment with the compiler code. Let's see.

Juha

I did some real tests.
The speedup by using gperf-generated code is simply negligable.

Michael.