Re: RFC: making TrieNode less memory-hungry

On 6/19/20 5:13 PM, Francesco Chemolli wrote:

>   I'm looking at the TrieNode code, and while it's super fast, it's
> quite memory-hungry: each node uses 2kb of RAM for the children index
> and any moderately-sized Trie has plenty of nodes. On the upside, it's
> blazing fast.

In Squid, TrieNode is only used be ESI, right? IIRC, ESI code quality is
rather poor, but I do not know whether it ESI was written to optimize
performance. If it was not, then is it a good idea to tune performance
of a library used exclusively by poorly written slowish code?


> How about changing it so that each node only havs as many children as
> the [min_char, max_char] range, using a std::vector and a min_char
> offset? Lookups would still be O(length of key), insertions may require
> shifting the vector if the char being inserted is lower than the current
> min_char, but the memory savings sound promising.

Do ESI users want to trade speed for memory savings? What memory savings
and speed reduction do you anticipate for a typical use case or two?


Thank you,

Alex.
_______________________________________________
squid-dev mailing list
[email protected]
http://lists.squid-cache.org/listinfo/squid-dev