Maps should only be freed on pool destruction

[Sean Kauffman]

Right now, in the interpreted code, maps are freed when pools are cleared as well as when they are destroyed. This leads to substantially more map malloc/free calls than are necessary, since mostly when a pool is cleared, that space will be reused. In the compiled code, for example, maps are not freed (ever) since they are statically allocated.

I believe it should be sufficient to check that a map is not-NULL to see if it is allocated, since pools are cleared prior to use. The one downside is that destruction becomes slightly more expensive, since the code will need to be updated to check the entire allocated space to see if there are any maps that need freed. Actually, maybe it can just check until it finds one that hasn’t been allocated and then it is safe to assume that all subsequent maps are not allocated. That might be something to check.

Overall, the goal of this is to reduce the execution time of the nfer monitoring algorithm in the interpreted code path.

[Sean Kauffman]

This might actually require excessive bookkeeping. The trouble, really, is that maps are allocated one at a time for pools rather than being part of a larger allocation. This is hard to change because of how maps are currently lazily allocated. Space is not made until something is stored, and then only as much as is required. This works great when there aren’t many keys to store in maps and poorly when there are lots of things to store in maps.

Unfortunately, a better solution would require taking into account the specification. Basically, pools could be instantiated using some parameters that specify some kind of expectation of the rough size and frequency of maps. The interval allocation function could possibly pass the interval name, then, to allow a lookup to see how big the map should be at allocation time instead of allocating lazily. This all sounds very complicated and it would be. Not clear if it would be at all worth it.