3 ms·
First, I assume the script was more complex than shown, and "jq" was not sufficient for some reason - because "jq" on such small document would likely be compar
by theamk 2y ago
First, I assume the script was more complex than shown, and "jq" was not sufficient for some reason - because "jq" on such small document would likely be comparable speed to C++ or even faster, while requiring no development effort at all.
The benchmark measures startup time, and Python is notoriously bad with it.
Why is the system requires a python app to be started many times per second? Can the system do localhost socket connection? Then we can have persistent Python daemon, and the speed would be many orders of magnitude faster than 22/second.
If for some reason it has to be process (3rd party system?), then a small C wrapper which does a socket connection to Python process would do the trick. This can potentially help with process management too, as it can launch python backend on demand, kinda like bazel does.
(This is all predicated on the fact that task is complex enough that it's worth setting up a dual-language system like this. I have no way to tell if that's true or not from the blog post)
- lifthrasiir 2y agoC++ being only 10x faster than Python also undermines the supposed claim, as Python code did materialize all JSON tree on loading while C++ version used the ondemand feature of simdjson. Even worse, he mentioned the input is "small", which means that I/O can be a very large factor in this particular benchmark. (Remember, simdjson is supposed to reach more than GB/s, so the input should've been at least 5 MB if no other overhead was involved. Is that even small?) It's shame that he definitely knows and could have done a thorough analysis to prove the point but didn't.
- anonymoushn 2y agoNEON is the worst case for simdjson performance. It's likely that the code actually ran on a server with better vector extensions than his laptop.
- viraptor 2y agoThere's also a few options in the middle: pypy, Nuitka, cython, and others can help with (almost) unmodified Python code and running it faster. Could be worth checking them before reaching for daemons and rewrites.
- forinti 2y agojq is the first thing I thought of. I'd certainly add a bash solution to this comparison. Maybe as a daemon to exclude the startup cost.