Hacker News Reader

Comment by dom96 | Hacker News Reader

Something to keep in mind while looking at the benchmarks in this article:

* Nim's `json` module will parse the full JSON file into memory, now I might be mistaken but AFAIK Crystal doesn't do this. The JSON module in the stdlib is good enough for most use cases, but there does also exist `packedjson`[1] which could be more performant for some use cases

* Regarding the base64 benchmark, you may want to read this: https://forum.nim-lang.org/t/5363 (this article does not include the patches made by treeform)

Benchmarks are easy to game, the only takeaway that can be had from an article like this is that on average the performance of software written in Crystal and Nim should be about the same.

1 - https://github.com/Araq/packedjson

View on HN

The JSON code is written in a way which forces the whole object to be loaded into memory - both in Nim and Crystal. It would be interesting to compare code clarity and benchmarks for a streaming JSON implementation though.

Agree that performance comparisons between Nim and Crystal are going to be largely moot. They're both "fast enough" for their target audiences.

FWIW, my experience with quite a few (usually small(ish)) tasks I implemented in Crystal is in line with the article's.

Once, a CSV-parsing and string-wrangling data batch job in python indicated it would take 27 hours to finish. I got annoyed and wrote a line-by-line translation in crystal. Writing it took about 40 minutes. It took a total of 2.5 minutes to run, that's two, almost three orders of magnitude.

As I said, this was a line-by-line translation, so whatever mistakes the python version had, the crystal version would have also had them. There are, however, a bunch of specialised python libraries (numpy et al) that weren't used, and I guess you could achieve some significant performance increases that way. Coming from ruby, I just happen to be quite productive in Crystal, to the point where I stumbled over the article's description as a "systems language".

I'm not sure why you're comparing Crystal to Python here, but just in case you've misunderstood something, Nim is a completely different language from Python. It borrows some bits of syntax (like I suppose Crystal does with Ruby, but I haven't used either of them), but otherwise it has nothing to do with Python, so a performance comparison of Crystal vs. Python doesn't say anything about Crystal vs. Nim.

There are probably ways to speed it up significantly in plain Python. For example, if you're processing strings you'll probably want to avoid iterating over individual characters and rely more on regular expressions, str.translate or other higher-level mechanisms.

Did you profile the Python code?

Another thing I noticed: the Nim code was compiled without the -d:release flag.

For example, the JSON test was compiled with:

    $ nim c -o:json_test_nim -d:danger --cc:gcc --verbosity:0 json_test.nim

I don't think that the -d:danger implies release (even if necessary to do things like disable bounds checking)?

It does imply release in latest Nim versions, `-d:release` still has some checks enabled, and `-d:danger` is full-on release mode with all possible checks disabled.

Ah, thank you for explaining! That makes sense.

I found that I can always optimize stuff in nim to be near C speed - without doing anything crazy non-nim like.

Stuff that is there might not be optimized yet. I hope as more people comb over the libraries we all get a boost here and there.

Reply on news.ycombinator.com