Re: Hash containers - some thoughts and recommendations

My point is that if you don’t really care about top performance use std::unordered_map. If you do care about performance using something that is performant like dense_hasg_map. It has been around since 2013 when Google open sourced it and there are benchmarks out there on it (https://tessil.g

Re: Hash containers - some thoughts and recommendations

Thing2: 1. struct Thing2 { 2. std::string _payload; 3. int _n{0}; 4. 5. Thing2(std::string_view text) : _payload(text) {} 6. Thing2(std::string_view text, int x) : _payload(text), _n(x) {} 7. 8. Thing2 * _next_name {nullptr}; 9. Thing2 * _prev_name {nullptr}; 10.

Re: Hash containers - some thoughts and recommendations

Is the superiority of open addressing independent of usage patterns? Does it have the same level of used versus allocated but unused memory? Is it assumed the first lookup for the chain bucket implementation is the head pointer of the chain? On Fri, Aug 24, 2018 at 12:46 PM, Bryan Call wrote: >

Re: [DISCUSS] Following redirects to 'localhost'

Sounds good let me take a look. On Fri, Aug 24, 2018 at 12:24 PM, Bryan Call wrote: > I am OK with it. I would add a default tag, so you can specify what > action to take by default if there is no match (e.g. > routable:follow,default:reject). > > -Bryan > > > > > On Aug 24, 2018, at 9:16 AM, A

Re: Hash containers - some thoughts and recommendations

Here's the code, but I fail see to the point if the goal is compare IntrusiveHashMap to some theoretical hash map rather than the actual alternative hash maps that have been proposed. I thought your specific recommendation was to use std::unordered_map instead, so that's what I tested against. Also

Re: Hash containers - some thoughts and recommendations

I stated that a better designed hash table (not a chained hash table) would have much better performance and that a double find would not be a performance hit. The benchmark was done with two chained hash tables, which are known not to have great performance. Can you post the source code of t

Re: [DISCUSS] Following redirects to 'localhost'

I am OK with it. I would add a default tag, so you can specify what action to take by default if there is no match (e.g. routable:follow,default:reject). -Bryan > On Aug 24, 2018, at 9:16 AM, Alan Carroll > wrote: > > Derek and I discussed this earlier this morning and we think the best >

Re: [DISCUSS] Following redirects to 'localhost'

Derek and I discussed this earlier this morning and we think the best option is to have a new configuration variable instead of bringing back the old one, something like "proxy.config.,http.redirect.actions STRING". The string would be of the format "tag[:action],tag[:action],...". The tag would

Re: Hash containers - some thoughts and recommendations

Alan sent me an article by skarupke a while back. He has devoted a lot of time to optimizing hashmaps. Talkhttps://www.youtube.com/watch?v=M2fKMP47slQ Code: flat_hash_map/bytell_hash_map.hpp at master · skarupke/flat_hash_map

Re: Hash containers - some thoughts and recommendations

I did some simple testing on IntrusiveHashMap vs. std::unordered_map. The first test was insertion and lookup, with 1009 items. The lookup loop was done 1000 times, each time looking up each item once, in a different order every loop, for roughly 1M lookups. The second case is a double indexed inse