That is not a properly specified or useful requirement.
1) Your benchmarks have to be validated to correspond to real life usage.
Especially problem sizes and specific structure. (Whether collisions are needed, what kind of queries etc.)
2) A proper performance specification is WCET or runtime histogram for given piece of code, which can be checked with a model checker.
3) It is a requirement to pass a given test "better". If that sounds good to your clients, well, you're selling a database to clueless people who somehow care about a specific benchmark...
Competitors will pick a different benchmark to brag about.
4) Problematic parts of the code have to be identified, specified and fixed. And tested. If you do not match performance spec by then you have a different problem and need to redesign the software including algorithms used most likely. Very expensive.
1) Your benchmarks have to be validated to correspond to real life usage. Especially problem sizes and specific structure. (Whether collisions are needed, what kind of queries etc.)
2) A proper performance specification is WCET or runtime histogram for given piece of code, which can be checked with a model checker.
3) It is a requirement to pass a given test "better". If that sounds good to your clients, well, you're selling a database to clueless people who somehow care about a specific benchmark... Competitors will pick a different benchmark to brag about.
4) Problematic parts of the code have to be identified, specified and fixed. And tested. If you do not match performance spec by then you have a different problem and need to redesign the software including algorithms used most likely. Very expensive.