Hacker News Reader

I just skimmed through the article but it seems that they refactored from allocating and copying substring to pointing at the substrings within the original string (inside a hot path). So 25x performance boost should be expected just from that and has nothing to do with GC or the language used.

View on HN

200gB in 2.5 hours is still only 22mB/s, I feel like I've seen blog posts of people going several orders of magnitude faster than that when the bottleneck is the sequential read of a big file on an SSD

I've written similar code before using absolutely bog standard idiomatic OOP Java. For a single threaded program I'd expect at least 1GB/s before any optimization. Most of the allocations in the loop that aren't the final records objects will get erased by JIT.

They are doing something very wrong.

Let me rephrase this for you

They're doing something slightly wrong that's making a non-bottleneck part of their code less optimal than it should be.

Millibytes per second?

See in french we don't even have the possibility for that kind of confusion because we named a "byte" an "octet" which also reflects its relation with the number 8

That way they don't get gigabytes and gigabits abbreviated with the same letters and we don't have to rely on a capitalization convention

Join the enlightened gigaoctet convention

Reply on news.ycombinator.com