|
|
|
|
|
|
by olliej
1342 days ago
|
|
|
This seems to not be entirely reasonable. [edit: apparently the author is a deno employee but did not choose to disclose such? If so then that throws any moral position they have out the window. The below however is still accurate to my reading of the complaints.] First up is the FFI test. On the one hand I think that this is a legitimate complaint, changing an existing benchmark for your comparisons is always suspect. That said I can see technically legitimate reasons for the change - for example if bun's ffi interface doesn't actually handle byte arrays as well as other runtimes. But in such a case that should be explicitly called out as a caveat. The sqlite complaint is not reasonable, if sqlite is being used as a demonstration of wasm performance there is nothing at all wrong with this test - if anything using wasm makes it more valuable as a comparison of runtime perf, otherwise you're very quickly going to just be benchmarking one native build of sqlite to another native build of sqlite. The React complaint - this just looks like bog standard formatted minified code, which is an absolutely reasonable thing to do - in fact I would argue it is a much better reflection of real world performance than using the non-minified code. Production websites only ever send minified content (at the react scale) and minification absolutely impacts page load performance, and historically could result in catastrophic runtime impact (though they're better at not doing this now). |
|
|
It seems like the author disclosed this a couple minutes after you wrote your comment.
> The sqlite complaint is not reasonable, if sqlite is being used as a demonstration of wasm performance there is nothing at all wrong with this test
Looking at that benchmark, it seems to be comparing Deno's WASM sqlite to Bun's native bun:sqlite, which I'd consider to be an unfair comparison.