3 ms·
It's yet another flawed microbenchmark. The RealBASIC version calls the inbuilt "chr" function while in C# it calls: public static char Chr(byte src) {
by gav 14y ago
It's yet another flawed microbenchmark.
The RealBASIC version calls the inbuilt "chr" function while in C# it calls:
public static char Chr(byte src)
{
return (System.Text.Encoding.GetEncoding("iso-8859-1").GetChars(new byte[] { src })[0]);
}
I'm sure there's some overhead to calling this 16 million times.
- Nican 14y agoI noticed the same thing. Modifying the code to make a simple cast made the code run from 5.6353 sec to 2.3411 sec, but this benchmark still shows very little about optimizations.
- profquail 14y agoThat may not even be the biggest flaw; using DateTime.Now as the timing mechanism for small benchmarks is pretty inaccurate because the resolution is rather poor. The recommended way is to use System.Diagnostics.Stopwatch, since that uses the CPU's built-in high-performance timer (HPET).
- ajanuary 14y agoIt also doesn't do any warm-up (run the code a few times untimed) which puts the JITer at a disadvantage.
- buffportion 14y agoWhy use strings at all? Guid.NewGuid() is built in, and way faster. Given that the C# code is almost willfully unoptimized, I'm not sure what the benchmark was meant to prove.
- ajanuary 14y agoTo be fair, it was trying to compare JIT vs. non-JIT. As futile as that me be via a microbenchmark like this, you need to compare as similar an execution path as possible. As it happens, the C# version is doing 16000000 more lookups for the Encoding than the RealBASIC version. Remove that, and C# - and by the premise of the post, JITters - wins.