Like I said I won't complain if you do the work.
Miss caches are good enough if you only want the performance boost, which is why after lots of dreaming about Boost::MultiIndexes I finally went ahead with one. But if you are willing to do the extra work separating the different rule types and optimizing the lookups for the each type
does improve the performance
and allow improving the security manager UI separating it to have a separate panel for each type and that's where it starts getting worth the trouble. But too much work for me, so I just took the low hanging fruit. A cache doesn't really need to synchronize with the actual rules, you just clear it if it might have an error in it... So much easier.
I think we should go with the ODs code unless we need a stable release before he can get it ready and properly tested. In that case my miss cache approach could be used instead. All it misses (it wasn't really ready for commit you know) is adding a limit on the cache size to prevent it from growing big enough to cause problems and miss caches for SHA1 and ED2K hashes. All of which someone like ryo could do in few minutes I am sure.
EDIT: And the cache and the rules really should have separate locks so that you can miss fast even when checking the list for something else. I didn't see the point doing that for the test, but not having connections lag because of a sanity check really is kind of the whole point.