

A persistent key-value server in 40 lines and a sad fact (2014) - signa11
http://java-is-the-new-c.blogspot.com/2014/12/a-persistent-keyvalue-server-in-40.html

======
callesgg
PS. The moving gif's make it very hard to read.

~~~
0942v8653
If you're using Firefox, go into about:config and change image.animation_mode
to none, then reload the page.

~~~
juliangregorian
Or just use any browser's inspector to delete them.

------
bradhe
Couple thoughts.

1\. 40 lines of glue code, sure. How much external code did he pull in/write?
2\. All of this is predicated on the idea that serialization/deserialization
is the primary bottleneck. This becomes _not_ your bottleneck when you've got
other distributed components in play.

------
ninjaroar
ChronicleMap looks really cool, i didn't know about it, but it seems like
exactly what i've been looking for.

I've been keeping an eye on apache directmemory, but that project seems to
have little activity.

does anyone here have real world experience with ChronicleMap in production
systems?

------
jpfr

        The test highlights an issue not covered by micro-
        benchmarking: Encoding and Decoding should perform
        similar, as factual throughput is determined by
        Min(Encoding performance, Decoding performance).
        For unknown reasons JDK serialization manages to encode
        the message tested like 500_000 times per second,
        decoding performance is only 80_000 per second so in
        the test the receiver gets dropped quickly:
    

At 500,000 messages/sec you can burn 6000 cycles per message on a 3Ghz core.

Probably he has a problem with malloc during the decoding phase. Every malloc
and every free costs between 300 (best case) and several thousand cycles
(syscall is required).

~~~
moru0011
its not "he" that's a JDK issue

------
ExpiredLink
But what is it? The author doesn't bother to describe problem definition and
context.

~~~
Alupis
He referenced Peter Lawrey, and the off-heap stuff he does with HFT systems,
so presumably it's somewhere along those lines.

------
amelius
If it is only 40 lines of code, why would you even use Java instead of e.g. C?

~~~
moru0011
Then its 4000 lines ..

~~~
ryanlol
Which is still significantly less than with java.

------
javaispoo
Might be quick when running but the jvm startup time is a pain. By the time
the java solution starts up, my c based solution has already finished.

~~~
sarnowski
[http://blog.ndk.io/2014/02/11/jvm-slow-
startup.html](http://blog.ndk.io/2014/02/11/jvm-slow-startup.html)

40ms sounds okay for me, even for most command line tools. Oh and I most
probably don't get a segmentation fault ;-)

~~~
juliangregorian
Sure wish my JVM started in 40ms. Here's ruby:

    
    
        $ time ruby -e "puts 'hello world'"
        > hello world
        >
        > real	0m0.076s
        > user	0m0.029s
        > sys	0m0.017s
    

And here's jruby:

    
    
        $ time ruby -e "puts 'hello world'"
        > hello world
        >
        > real	0m1.161s
        > user	0m2.050s
        > sys	0m0.093s

~~~
ssmoot
Your JVM does. jruby.jar is megabytes of reimplementation and mapping of the
Ruby stdlib onto the JVM. Plus in this example, loading a Ruby parser and
interpreter.

Here's executing an assembly (über-jar) I wrote in Scala:

    
    
      → time scripts/couch 
      Please provide a basePath and a valid command. ("backup", "restore", "truncate", "migrate" or "migrate-all")
    
      real	0m0.375s
      user	0m0.415s
      sys	0m0.073s
    

That's basically just `java -jar couch-utils.jar`.

A few hundred ms on my 1.2GHz MacBook. And this includes a bunch of Akka
Actors.

