Hash, IndexOf, Lookup, Performance, Search, Sorted, String
As a followup to the previous String Lookup: Hash, Sorted or Unsorted here is a look at what happens for longer strings.
When the string you’re searching have more than a dozen characters, and you only have a few hundreds of them, a clear winner emerges.
When looking up a string, what is the fastest strategy?
A hash map, a sorted list or an unsorted list?
Of course it depends on how many strings you have, but where are the cutoff points?
Here is a quick test, and an interesting tidbit is uncovered…
(more…)
A trivial way to turn a case-sensitive String hash function into a case-insensitive one is to to pass a lower-case (or upper-case) version of the String.
However, in our days of Unicode strings, this is not innocuous…
[This is a guest post, written by Primož Gabrijelčič, www.
One thing interested me since I started reading Eric’s series on string concatenation performance – how would different memory managers compare in a multi-threaded scenario. Today I decided to spend an hour finding out…
edit 18/11: the tests were run with debug mode, which affected TTextWriter very negatively (TWOBS is also affected a negatively, but less, and StringBuilder and Trivial aren’t affected much). I’ll be repeating tests with more memory managers and in more stable conditions in the next few weeks.
By popular request, here is the source code used for the previous String benchmarks StringConcatBench.zip, essentially to test alternative memory managers.
The source is nothing complicated as you will see, just a set of simple function with the test cases, and a couple function that measure run times.
After looking at String concatenation and String Building in Delphi, and as a conclusion, it’s time to have a brief look at what happens in multi-threaded settings, such as in a server pushing JSON, XML or some other text data.
As a followup to the String Concatenation article, let’s take a look at a less trivial case: what if instead of concatenating a couple strings, you want to concatenate a few hundred?
Sounds like a task at which TStringBuilder should excel, but one should never assume, and always measure.
You may all know about String concatenation in Delphi, but do you know about the implicit String variables the compiler may create for you?
Along with the implicit variables come implicit exception frames, and a whole lot of hidden stack juggling, which can quickly become hidden complexity bottlenecks.
One of the “novelties” of the NextGen Delphi compiler is immutable strings, which I find quite puzzling, for lack of a better word, given that Delphi already had reference-counted copy-on-write strings, and the NextGen compiler uses reference-counted strings.
I always considered that Delphi’s String type was one of its remaining strong points, being a high-level abstraction (higher than Java’s or .Net’s String/StringBuilder dichotomy) with excellent low-level performance (on par with C/C++ character arrays).
From the recent discussions, it appears many don’t know what makes/made Delphi String so special, so here is a quick summary.
In a now infamous and enormous thread I won’t name, Allen Bauer dropped a bomb:
<bomb>Oh, and strings may become immutable and 0-based
…</bomb>