<div dir="ltr">I have a multi-index BMI (Boost 1.44), with an ordered_non_unique index on a"name" string field, which is lexicographically ordered.<div><br></div><div>I'm searching for the range of values of the form "$prefix $integer", i.e. "foo 1", "foo 99", etc...<br> </div><div><br></div><div>to obtain this "range", I initially used (pseudo-code):</div><div><br></div><div>auto begin = by_name_index().lower_bound(prefix + " 0");</div><div>auto end = by_name_index().upper_bound(prefix + " 9");<br> </div><div><br></div><div>and within the range I test the suffix for its number'ness and keep the largest number.</div><div><br></div><div>But I was surprised to see it performed badly for large number of calls.</div> <div><br></div><div>I switched to using instead:</div><div><br></div><div><div>auto begin = by_name_index().lower_bound(prefix + " 0");</div><div>auto end = by_name_index().lower_bound(prefix + " :");<br> </div></div><div><br></div><div>And this performs much better (20x).</div><div><br></div><div>The "corpus" of names of this particular test may be skewing the results, since entries are added to the BMI with monotonically increasing number suffixes, and all entries have the prefix I'm looking for, yet I'm very surprised of such a large performance difference between the lower/upper version, and the lower/lower version.</div> <div><br></div><div>Anyone has a clue what could be going on? Thanks, --DD</div><div><br></div><div>PS: I'm assuming the two versions are equivalent. Let me know if I'm mistaken please. This is not yet thoroughly tested.</div> </div>