getFiltersForPolicy is a performance hotspot

[RobDickinson]

phileas-benchmark profiling shows that significant CPU time can be spent in the getFiltersForPolicy method (even with the recent addition of caching there). It might be worth considering a second level of caching where the result lists themselves don't have to be created each time?

[RobDickinson]

@jzonthemtn having revisted this with latest code I think this is just an artifact of how this benchmark works.

If you process very small strings (<32 bytes), hundreds of thousands of times per second, and do nothing else, then the overhead for getFiltersForPolicy can look significant like I showed originally. (and that's what I was doing at the time, microbenchmarking with mostly small strings)

Now that we have some real and non-microbenchmarky integrations, I did some analysis on a few more realistic workloads, and I didn't see one where getFiltersForPolicy was significant.

I think I was up pretty late and mis-interpreted this as an opportunity to optimize, cause who wouldn't want ~20%? 😀

I humbly withdraw my complaint

[jzonthemtn]

Sounds good! Appreciate the update.