3 ms·
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 str
by ifdefdebug 3y ago
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.
- sebstefan 3y ago200gB 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
- xmcqdpt2 3y agoI'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.
- sebstefan 3y agoLet 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.
- Kwpolska 3y agoMillibytes per second?
- sebstefan 3y agoSee 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