Re: [squid-dev] RFC: making TrieNode less memory-hungry
> > 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? > > In light of the fact that it's only used by ESI, I think it's not worthwhile investing in it. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] 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 squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] Proposed focus for Squid-6
On 6/30/20 6:59 PM, Amos Jeffries wrote: > I have been asked a few weeks ago about what the "goal for Squid-6" is > going to be. What does it mean to claim that "Squid v6 goal is X"? Does "reaching X" become a precondition for the v6 release? Something else? Our RoadMap page talks of _features_ (with specific properties) driving release process, not goals. I assume the two concepts are different, but I do not know what the term "goal" really means here. Does the paragraph quoted below represent a complete answer to my question or just a partial description of what we are trying to define here? > It just gives people some rough direction to > consider when struggling with selecting of new work to start. IMHO, Squid work selection should be primarily driven by developer-specific factors that usually have little to do with Project-declared release goals, whatever they are. Until the meaning of "release goal" is clear to me, I can only comment on the validity of the proposed goals from a general "What is a good goal in a software development project?" point of view. Please do not misinterpret my responses below as an agreement (or disagreement) regarding adding those items as v6 release goals. As of now, I see no reason to have release goals other than the already established practice of tracking TODO features on the RoadMap. I am very open to changing my position, but that change would require developing a shared definition of the term "release goal". Hence my question above... > The last few version we have focused on C++11 optimizations and code > upgrades. I do not think this summary is meaningful or accurate, but it is a matter of opinion/perspective. > 0) the ongoing project to clarify OS support and testing. I would support that project if you replace "clarify" with "define" or something similarly meaningful/measurable. > 1) remove features that have been deprecated since Squid-3 days. This goal needs polishing: All such features? Some features we agree on (e.g., the two you listed explicitly -- WAIS and ICP)? What determines that feature F has been deprecated "since v3 days"? > 2) proposing some next features to be removed ASAP, possibly removing > them this release. > - send-announce removal > - SMB_LM helper removal This needs to be rephrased as a meaningful goal. Perhaps you meant "Removal of the following features: ..."? If yes, we need to make a decision for each feature. It is not clear (to me) whether the two specific examples have something in common here. > 3) drop (all?) bitrotten code Even with "all" in place, this is not a valid goal due to the vagueness of the term "bitrotten code". > 4) statistic addition to measure feature use. To improve admin ability > to answer our "are you using this feature" requests. I think Squid usage reporting would be a very nice feature (at virtually any granularity) _if_ we have enough admin support to enable such reporting by default. Perhaps we should ask on squid-users first? HTH, Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
