5 ms·
If you're writing JS you cannot beat JSON.parse, because you're running the most optimized C++ implementation of JSON which will outcompete any decoder written
by esrauch 1mo ago
If you're writing JS you cannot beat JSON.parse, because you're running the most optimized C++ implementation of JSON which will outcompete any decoder written JS itself.
Which is not a very generalizable situation.
- ltbarcly3 1mo agoOk but that's the point. You are just explaining why the 'protobuf is faster' claim is generally false.
- okanat 1mo agoIt is generally correct. When both implementations are completely in the same language Protobuf will win. Instead of a pure-JS implementation one can also make a FFI module for Protobuf. The comparison that's being made is equivalent to implementing quick sort in Python and bubble sort in C++ and then declaring bubble sort is the better alternative. Anyone with a healthy understading of computer science and programming experience will not make bullshit claims like that.
- ltbarcly3 29d agoYou say 'generally correct', but then to make it correct you have to make a bunch of specific constraints. That's not general. I'm comparing the FFI using library in python to the json library in python, and json is faster for me. I showed how in the post. You are welcome to find my mistake.
- esrauch 28d agoI was the grandparent reply and I meant to only carve out "you cannot write anything in JavaScript faster than anything written in tuned C, and json.parse is the latter". Which link were you comparing FFI in python to json in python? The link I see seems to be about pure JavaScript language Protobuf impls vs json.parse?