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 squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
