Hacker News Reader

Comment by jcfrei | Hacker News Reader

> There are collections for much more memory-efficient (and faster) maps and things, and also efficient (and fast) JSON parsing etc. I have evaluated and benchmarked and adopted a few of these kinds of things.

That sounds very interesting. Can you provide links to the benchmarks for fast JSON parsing (libraries)? And the fast maps?

View on HN

I can quickly list our findings (from testing on our specific actual workloads; ymmv etc):

For collections, we used to use trove but migrated to fastutil a few years ago.

For JSON parsing, we are processing lots of very small messages, so use LazyJson. The biggest downside to LazyJson is it doesn't have cheap iteration of keys; the framework could easily provide it. For larger documents, say over a few MB, libraries like Jackson are faster.

Yeah, perhaps Java isn't the right tool for our job. And yeah, more recent benchmarking and testing might suggest newer, better libraries than those I have just listed.

Its horrific the lengths you have to go to to get good performance Java for the workloads we have; python prototypes run much faster with pypy, and I think that is really about heap management more than code generation.

For those of us who know C/C++, its kinda uncomfortable when staring at code and thinking "that temporary string there? 40+ bytes just for the object header!" and things. But, of course, there are advantages to working in memory-safe languages.

C# and its structs, yummy.

Thanks!

Wow. I just replaced Java HashMap<Long,Object> with fastutils map for critical cache on a very compute-heavy project of mine, and it instantly got 25% faster. Thank you.

There is another benefit from using the fastutil library, decreased memory usage, which in some cases very significant depending of course on your data structures.

For the last few years, the fastest of the hash map programs shown on the benchmarks game has used fastutil

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

> For those of us who know C/C++, its kinda uncomfortable when staring at code and thinking "that temporary string there? 40+ bytes just for the object header!" and things. But, of course, there are advantages to working in memory-safe languages.

And of course, there are memory-safe languages that don't use 40+bytes-long object headers, and are in fact highly competitive with C/C++. For one thing, Go can be made memory safe if you avoid concurrent mutability.

> For one thing, Go can be made memory safe if you avoid concurrent mutability.

golang's performance won't be as good as Java's.

Not if you compare on same hardware but the amount of memory itself that you can end up saving you can re-invest it into compute. I've seen massive perf/$ gains for log-parsing and memory-mapped data profiling use cases.

Not even that is required - the popular synthetic benchmarks have Golang (1.14) beating out Java which is echoed by a lot of users and their usecases. A lot of Java claims seem to come from future/unreleased efforts which muddy a lot of comparisons.

[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Where is it beating Java by any significant amount? The regex benchmark uses Java's native regex matcher, whereas the golang implementation uses a PCRE regex matcher, so not an apples to apples comparison. The mandelbrot benchmark are minutely different on my machine (2.06s vs 2.13s). Note that the test machines that websites use are quite old (certain optimizations or available APIs the JVM has are not supported by those older processors).

Now if you look at the bottom of the list, you'll see where Java far outperforms golang, especially in the binary-trees benchmark (12.67s vs 9.14s and 25.19s vs 8.28s in favor of Java both times).

Your original assertion:

> golang's performance won't be as good as Java's

My refutation followed with updated synthetic benchmark results.

Your serve I believe. If you have data to prove that, for the workloads in the article, Java would outperform Go I would be very interested in seeing it.

Synthetic benchmarks are not representative of real world performance. People who have dealt with large programs can testify to this. Yet, the binary-trees benchmark is allocation heavy, and typical of workloads similar to those described in the article, and it shows how far ahead Java is able to pull compared to golang.

It's a fact that the JVM's JIT and GCs are way more advanced than what golang has to offer.

> C# and its structs, yummy.

Yep. Java should also be getting value types, hopefully soonish: https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-back...

C# really hits a weird sweet spot that people on the outside don't really recognize due to C#'s heritage as a Java clone , previous windows dependencies and anti-MS bias of the early 00s.

While i still really can't stand C#'s VB based naming conventions and property happyness the language is extremely practical in many situations.

Writing LINQ you still think mostly in SQL but don't have to worry about string escaping, while on the other side of the spectrum you have structs,spans,stack allocs and in/out/ref vars that gives the code written in the language a chance to keep up with C/C++ on modern CPU's where cache-friendlyness is paramount.

Java on the other hand has opted to avoid much of this and thus has to depend on GC's magically becomming while when working with C# developers can dig down and optimize things on their own instead.

Reply on news.ycombinator.com