Oh my, where to start... This little article shows everything wrong with software devs these days :) First of all, the implementations aren't doing the same thi

Oh my, where to start... This little article shows everything wrong with software devs these days :) First of all, the implementations aren't doing the same thing, which is bad for a proper comparison; but others pointed that out already. What bugs me the most, though, is the atrocious JavaScript implementation. On my aging machine, none the of the browsers I tried it on (Edge, Opera, Chrome, and Firefox) - not a single one! - even ran the original version. All of them refused to run the script and timed out. I did a very, very simple change and just used the proper tool for the job - TypedArrays: function testSort() { const length = 100_000 const arr = new Uint8Array(length) for (let i = 0; i < arr.length; i++) { arr[i] = Math.random() * 255 // the original code produced float values here } const temp = new Uint8Array(length) for (let i = 0; i < 500; i++) { temp.set(arr, 0) // shorter than a manual for-loop and about 6+% faster temp.sort() } } And wouldn't you know it, Firefox now runs this function. I did my testing on https://jsbench.me https://jsbench.me, put the function in the setup section and the actual call in test cases. I added another function, this time using an Int32Array instead and random values between -1_000 and +1_000. Just to be thorough and because I found it interesting, I also added a Float32Array version this time using the result from Math.random() without any scaling. This leads to an interesting observation: there seems to be a huge difference in optimisation between Firefox and Chromium-based browsers with TypedArrays: Test | Performance | Browser -----------------+---------------------------------+----------------- testSort_uint8 | 0.75 ops/s±1.8% (~1.33s/call) | Edge testSort_uint8 | 29.33 ops/s±2.3% (~34ms/call) | Firefox -----------------+---------------------------------+----------------- testSort_int32 | 0.64 ops/s±1% (~1.56s/call) | Edge testSort_int32 | 1.44 ops/s±0.2% (~694ms/call) | Firefox -----------------+---------------------------------+----------------- testSort_f32 | 0.16 ops/s±0.6% (~(~6.25s/call) | Edge testSort_f32 | 1.49 ops/s±0.3% (~671ms/call) | Firefox In Firefox, the results where *really* interesting. The dramatic difference between uint8 and int32 in particular is quite astonishing. Unlike the author, I fund zero difference between Edge, Opera, and Chrome in terms of performance, which doesn't surprise me as they all use the same engine. While Firefox's SpiderMonkey engine is faster in all scenarios, the uint8-version is faster by an order of magnitude, whereas V8 shows comparatively little difference (~15%) in the integer case and absolutely tanks performance with float values. This last result in particular might explain, why the original version was both unable to start on my machine and also slow in the author's browsers. I hope you found this as interesting as I did and maybe even find a place to apply these findings in your projects. Cheers.