Top 5

[Sascha Katzner]

Sergey Gromov wrote:
> This is the whole point.  The benchmark is valid because it performs
> the same *task*, and the task is somewhat close to real world.  It
> measures *time*, which is universal.  The compared languages use
> different approaches and techniques to achieve the goal, that's why
> benchmark is useful.  It allows to justify usefulness of these
> languages for a particular class of tasks.

My point was, that it is *not* the same task both programs perform. The
D version has to do a lot more because it accounts for multi-byte
codepoints in UTF8, but the Java version doesn't account for surrogate
pairs. I bet if you simply scan byte-wise through the D UTF8 array for
whitespaces without converting them to UTF32 it would perform even
better, but that wouldn't be a fair comparison neither. ;-)

It's like if you would remove all runtime security checks and exception 
code from a programm and benchmark it against the original version... it 
simply doesn't make much sense. ;-)

>> - At least in runCharIterateTest() you also convert the D UTF8
>> string also additionally into an UTF32 string, in the Java version
>> you did not do this.
> 
> Same as above.  If they were using the same approach there wouldn't
> be much to benchmark.

That's my whole point here, you can use the exact same approach in D as
in Java and achieve more or less the same speed. That's the beauty of Ds
string approach.

> Why don't you mention, for instance, that Java is a virtual machine?

Because that is irrelevant in this context.

LLAP,
Sascha