String Compare Performance in D

A while ago I was measuring performance of string comparison in .NET. Today I played with string type in D programming language and decided to make similar tests.

D is relatively new language with some good perspectives (by the way Andrei Alexandrescu is engaged in D development).

Here is relatively simple code, that I have used to make the tests:

import std.string;
import std.date;
import std.stdio;

string cmp1 = "SomeString";
string cmp2 = "Someotherstring";
auto iters = 100000;

void test_f()
{
    for(int i = 0; i < iters; i++) { auto res = icmp(cmp1, cmp2); }
}

void test_equal()
{
    for(int i = 0; i < iters; i++) { auto res = cmp1 == cmp2; }
}

void main()
{
    ulong[] results;
    int mean1 = 0;
    int mean2 = 0;
 
    for(int i = 0; i < 5; i++)
    {
        results = benchmark!(test_f, test_equal)(1, results);
 mean1 += results[0];
 mean2 += results[1];
 writefln("Test_f: %d", results[0]);
 writefln("Test_equal: %d", results[1]);
    }
 
    mean1 = mean1 / 5;
    mean2 = mean2 / 5;
 
    writefln("Mean Test_f: %d", mean1);
    writefln("Mean Test_equal %d", mean2);
}

Test results where interesting:

Test_f: 21
Test_equal: 2
Test_f: 21
Test_equal: 2
Test_f: 22
Test_equal: 2
Test_f: 14
Test_equal: 1
Test_f: 12
Test_equal: 1
Mean Test_f: 18
Mean Test_equal 1

18 millis for 100000 iterations looks pretty nice. It is faster then .NET string case insensitive ordinal string comparison. If you remember: .NET version completed in about 26 milliseconds. Second test function just compares two values for equality, I assume that mere pointer compare is made.

I have decided to give this relatively new language a try, it is highly possible that there will be more posts about D in this blog :).

Local Computer Connection Failure When Using ActiveSync

Not so long ago I have encountered strange problem with Windows Mobile device connectivity when using ActiveSync.

Here is long story cut short and the solution I came up with.

Server software was located on the Host1. Windows Mobile device was supposed to connect to that server software.

When device was cradled and connected to Host1's ActiveSync it was unable to open connection to server software. However, it could connect perfectly well to the same server software located on Host2. Strange?

It turned out that for local connections (connections to the host where ActiveSync is located) ActiveSync substitutes remote address device wants to connect to with 127.0.0.1. It is loopback address.
Server software was listening on particular IP address (at that time this was by design).
I discovered this by using netstat command and connecting with Windows Mobile browser to local IIS web server.
The command I have used was: netstat -anbp tcp

Obvious fix: listen on 0.0.0.0 (in .NET it is IpAddress.Any).
Any time when connection to local computer from cradled device fails - check if software you are connecting to listens on all IP addresses or is configured to listen on loopback (127.0.0.1) too.

Performance Issues When Comparing .NET Strings

Every time when you want to use string.Compare("str1", "str2", true) for case insensitive string comparison - think twice.

To illustrate my point I am bringing this example:

int iters = 100000;
string cmp1 = "SomeString";
string cmp2 = "Someotherstring";

Stopwatch sw = Stopwatch.StartNew();
for(int i =0 ;i < iters;i++)
{
    int res = string.Compare(cmp1, cmp2, true);
}
sw.Stop();

Console.WriteLine("First:" + sw.ElapsedMilliseconds);
            
sw = Stopwatch.StartNew();

for (int i = 0; i < iters; i++)
{
    int res = string.Compare(cmp1, cmp2, StringComparison.OrdinalIgnoreCase);
}
sw.Stop();

Console.WriteLine("Second:" + sw.ElapsedMilliseconds);

Quick question which method is faster, first or second?

...
...

Here is my result in milliseconds:
First:77
Second:26

Wow, second sample nearly 3 times faster!!!
This is because first method uses culture-specific information to perform comparison, while the second uses ordinal compare method (compares numeric values of each char of the string).

Knowing the above we can deduce general rule of thumb: when culture-specific string comparison is not required we should use second way otherwise first one.