>A few folks asserted that the CPU-heavy nature of calculating Fibonacci numbers isn’t representative of web servers generally. Multiple people noted that – in

>A few folks asserted that the CPU-heavy nature of calculating Fibonacci numbers isn’t representative of web servers generally. Multiple people noted that – in the Swift implementation, at least – the majority of the CPU time was spent doing the Fibonacci calculation. Some felt this was therefore not a useful benchmark of Vapor itself. A lot of this boiled down to the “no true Scotsman” problem, which is very common in benchmarking, with a bit of perfect world logical fallacy peppered in, trying to identify the One True Representative Benchmark Well, it doesn't take any True Scotsman to understand that "busy calc of Fibonacci" is a crap web server benchmark. >Accusations were made pretty quickly that the benchmark is “unfair” to Swift because Swift doesn’t – it was asserted – have a properly-optimised “BigInt” implementation, unlike all the other languages tested. No real evidence was given for this. Even if it were true, it doesn’t invalidate the benchmark – in fact, it just makes the benchmark more successful because it’s then highlighted an area where Swift is lacking. This takes defensiveness to the next level. Sure, it might highlighted an area where Swift is lacking. Even lead to opportunity for improvement there. But an even more important question is: does is say anything about what it was supposed to say (and the conclusions they drew from it), that is: whether Swift is good for web serving? In that end, are BigInts a big part of web serving? I've used them maybe a couple of times in 20 years of web/APIs, in very specialized cases. Instead of finding various excuses why the benchmark is not crap, maybe write a decent benchmark to begin with? One can find stupid non-relevant bottlenecks for any language (e.g. nerf Node by blocking work, find some PHP operation that's hella slow and lean on that, etc).