The first issue I can see with that code is it's not doing what he expects. He does this to read the file into a StringBuffer:<p><pre><code> bf.lines().forEach(s -> sb.append(s));
</code></pre>
However, this ends up reading all the lines into one giant line, since the String's that lines() produces have the newline character stripped. This leads to the second lines() call to read a 23MB line (the file produced by gen.py). This is less than optimal.<p>The fastest version I managed to write was:<p><pre><code> public void readString5(String data) throws IOException {
int lastIdx = 0;
for (int idx = data.indexOf('\n'); idx > -1; idx = data.indexOf('\n', lastIdx))
{
parseLine(data.substring(lastIdx, idx));
lastIdx = idx+1;
}
parseLine(data.substring(lastIdx));
}
</code></pre>
Not the prettiest thing, but it went from 0.594 GB/s to 1.047 GB/s. Also, it doesn't quite do the same as the lines() method, but that's easily changed.
I don't know what Java's BufferedReader is doing, but it's probably not the optimal thing in terms of IO throughput. I would blame the algorithm long before blaming anything inherent about the JVM.<p>Erlang is another language where "naive" IO is kind of slow. <a href="https://github.com/bbense/beatwc/" rel="nofollow">https://github.com/bbense/beatwc/</a> is a project someone did to test various methods of doing IO in Erlang/Elixir, and their performance for a line-counting task, relative to the Unix wc(1) command.<p>It's interesting to see which approaches are faster. Yes, parallelism gains you a bit, but a much larger win comes from avoiding the stutter-stop effect of cutting the read buffer off whenever you hit a newline. Instead, the read buffer should be the same size as your IO source's optimal read-chunk size (a disk block; a TCP huge packet), and you should grab a whole buffer-ful of lines at a time, do a <i>pattern-matching binary scan</i> to collect all the indices of the newlines, and then use those indices to part the buffer out as <i>slice references</i>.<p>This achieves quite a dramatic speedup, since most of the time you don't need movable copies of the lines, and can copy the line (or more likely just part of it) yourself when you need to hold onto it.<p>This approach is <i>probably</i> also already built in to Java's "better" IO libraries, like NIO.
Honestly, it seems that nearly everyone here is missing his point.<p>Some of the blame for that probably lies with his headline choice, but he clearly states at the end of this post:<p>"""
This is not the best that Java can do: Java can ingest data much faster. However, my results suggest that on modern systems, Java file parsing might be frequently processor-bound, as opposed to system bound. That is, you can buy much better disks and network cards, and your system won’t go any faster. Unless, of course, you have really good Java engineers.<p>Many firms probably just throw more hardware at the problem.
"""<p>It's not <i>about</i> this piece of code. It's not even about Java In the previous post he mentions at the start of this one, he pointed out:<p>"""
These results suggest that reading a text file in C++ could be CPU bound in that sense that buying an even faster disk would not speed up your single-threaded throughput.
"""<p>So, I take his point to be that one shouldn't make assumptions about performance. Rough performance scales -- such as have been posted here many times (e.g. [1]) -- make great rules of thumb for implementation choices or as a guide for where to look first for bottlenecks. To optimize in the <i></i>real world<i></i>, though, you're best served using <i></i>real measurements<i></i>.<p>[1] <a href="https://www.prowesscorp.com/computer-latency-at-a-human-scale/" rel="nofollow">https://www.prowesscorp.com/computer-latency-at-a-human-scal...</a>
The post does nothing to explain how and why, it just throws a couple of outputs from a non specified machine and does no comparison.<p>It has no baseline and no specs. For all I know, he could have got his 0.5 GB/sec on ab old Pentium II processor.<p>There is no analysis.<p>I am perplexed.
I'm amazed at how upset some commenters are about a blog post that did a toy experiment and didn't actually make any strong claims.<p>I'm actually a stickler about good benchmarks - it riles me when people draw sweeping conclusions from poorly-designed experiments. Lemire is actually one of the good ones. If you want something more fully developed than a blog post, read one of his papers.<p>I personally really enjoy his blog because of this - he's good at picking interesting exploratory experiments that provide some insight, without trying to over-generalize from the results. If you read his conclusion, the point is that there is a good probability that even relatively simple programs are CPU-bound. His experiment supports that point. My experience also matches that - I've seen a lot of data processing code that could be I/O bound in theory (i.e. a perfect implementation could max out CPU or network) but is CPU bound in practice. Usually because of string manipulation, regexes, or any number of other things.<p>> This is not the best that Java can do: Java can ingest data much faster. However, my results suggest that on modern systems, Java file parsing might be frequently processor-bound, as opposed to system bound. That is, you can buy much better disks and network cards, and your system won’t go any faster. Unless, of course, you have really good Java engineers.
This is absurd, the original platform libraries do not account for the fastest use-cases in any specialized IO case.<p>Java NIO channel should have been used for this. It was demonstrated back in the early 2000s with the "Grand Canyon" demo achieving very good throughput for its time, and it's still the gold standard.
So what's the reason for this? Is it maybe because of some unicode shenanigans? Java characters are 16bit iirc, and strings have some forty bytes of constant overhead.
Java has many inefficient parts. For example there's no immutable array concept (or owning concept, like in Rust), so there's a lot of unnecessary array copies happens in JDK. String is not well designed. There was an attempt to abstract String concept into CharSequence, but a lot of code still uses Strings.<p>I made a similar benchmark. The idea is as follows: we have 2 GB byte array (because arrays in Java have 32 bit limit, LoL) filled with 32..126 values, imitating ASCII text and 13 values imitating newlines.<p>The first test is simply does XOR the whole array. It's the ideal result which should correspond to memory bandwidth.<p>The second test wraps this array into ByteArrayInputSteram, converts it into Reader using InputStreamReader with UTF-8 encoding, reads lines using BufferedReader and in the end also XORs every char value.<p>For 2 GB I have 516 ms as an ideal time (3,8 GB/s which is still almost order of magnitude less than theoretical 19.2 GB/s DDR4 speed) and 3566 ms as a BufferedReader, so you can have almost 7x speed improvement with better implementation.<p>Benchmark: <a href="https://pastebin.com/xMD4W8mn" rel="nofollow">https://pastebin.com/xMD4W8mn</a>
Eh, he didn't use NIO. BufferedReader is an ancient Java relic. Like reading from STDIN in c, it's not made to be fast, it's there for convenience and backwards compatibility.<p>Read a file using something like Vert.X, which is optimized for speed. I'm 100% confident it will be faster than the naive c approach
One thing that jumps out at me is the test code writes to "volume" variable in the read loop, I assume for counting the number of bytes in the file, but never reads it back. A clever compiler will optimize away those writes, the string length check, the loop over the lines, and actually reading the file.<p>I'm not saying that's happening here, but it's a basic fact when writing benchmarks that you have to actually test something real and not a transient property of the program <i>after</i> the compiler has had its chance to be really smart.
At least two problems with the java code. Concatenation of strings using the plus operator creates a new string and copies the content of the old, that pushes the complexity of the code from o(n) to o(n2) where n is the number of lines. Secondly order is not guaranteed with the for each operation on streams.<p>The correct way to do it is using collect(Collectors.joining(“\n”)) or straight forward imperative style (without streams).<p>I don’t think the general statement holds (that java or buffered reader is cpu bound in particular).
Java is... java.<p>I was once working on an Android app on a cheap custom board with 128 M ram (don't ask why Android on a single function custom board, wasn't my decision).<p>Among other things, I had to parse a 80000 line csv file. Splitting and the rest of the processing created so many temporary strings the system ran out of ram. We eventually gave up.