6 ms·

> 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 benchm

by jcfrei 6y ago

> 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?

willvarfar 6y ago
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.
- jcfrei 6y ago
  Thanks!
- laegooose 6y ago
  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.
  - chupy 6y ago
    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.
  - igouy 6y ago
    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/program/knucleotide-java-1.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- zozbot234 6y ago
  > 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.
  - apta 6y ago
    > 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.
    - hashhar 6y ago
      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.
      - hactually 6y ago
        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/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
        apta 6y ago
        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).
- apta 6y ago
  > C# and its structs, yummy. Yep. Java should also be getting value types, hopefully soonish: https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-back...
- whizzter 6y ago
  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.

by jcfrei 6y ago

willvarfar 6y ago

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.

jcfrei 6y ago
Thanks!
laegooose 6y ago
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.
- chupy 6y ago
  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.
- igouy 6y ago
  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/program/knucleotide-java-1.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
zozbot234 6y ago
> 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.
- apta 6y ago
  > 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.
  - hashhar 6y ago
    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.
    - hactually 6y ago
      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/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
      - apta 6y ago
        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).
apta 6y ago
> C# and its structs, yummy. Yep. Java should also be getting value types, hopefully soonish: https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-back...
whizzter 6y ago
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.