Using stl containers is not the issue, most people use stl containers in their default mode. My point was to use custom allocators with such containers. Specifically stack based ones if the container will only exists within a function call etc. perhaps even used EA-STL

As for expression templates, its not all about compile time computations, most often than not its a mechanism to explicitly specify how a computation should be done - this happens a lot in linear-algebra based implementation - check out the various uses in Blitz++, Boost Fusion, Boost Graph etc..

Also note move semantics weren't used with the compiler/library mentioned in the paper.

In short if the above were done/used the difference would have been MUCH greater.

The paper doesn't talk about using:

1. Custom allocators (stack and pool based)

2. Move semantics

3. Modern C++ idioms such as expression templates

I believe if these were used, the performance would have even better and left the rest "truly" in the dust...

I believe they use two sets of bloom filters one for known bad sites and one for known good sites - each is roughly ~1.5MB large and can be found in your google install dir, Search for files with the word "filter" in their name.