>> It's the pointers in each list member. If nothing else, a list >> member will have a pointer to the next member. The MRU list has >> next, previous, and next-hash-chain pointers.
> Ouch, I'd try to fix that. Maybe a different list layout model? > Given the churn in the MRU list it may be a linked list is best. > But worth a look. Any suggestions? I can't think of any obvious way to do better. The code has a hash table to find existing slots. It has a linked list for the IP addresses that hash to the same slot. It keeps a linked list of slots sorted by age. That has next and previous links to you can remove a slot and move it to the head. That also lets you find the oldest slot so you can consider recycling it. We could rewrite the code to use a big array. That requires the space to be contiguous. We could either pre-allocate the max size or copy over the whole thing when growing it. Neither is attractive. That's assuming array indexes would be smaller than pointers. We could give each slot a sequential slot number rather than index. That needs a big table/array of pointers indexed by slot number. That trades 3 pointers for 1 pointer plus 3 indexes. If indexes are 32 bits, that's 3*8 vs 1*8+3*4 for a savings of 4 bytes. I don't think that's worth the complexity. If indexes would fit in 21 bits, we could pack 3 of them into 8 bytes. That would save 4 more bytes, but it limits us to 2 million slots. I'm already using 3 million. Time to move on. There is plenty of lower hanging fruit. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list [email protected] http://lists.ntpsec.org/mailman/listinfo/devel
