A persistent key-value server in 40 lines and a sad fact (2014)

http://java-is-the-new-c.blogspot.com/2014/12/a-persistent-keyvalue-server-in-40.html

by signa11 • 11 years ago

78 34 11 years ago

java-is-the-new-c.blogspot.com

callesgg• 11 years ago

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

kyberias• 11 years ago

Don't look at the "moving gif's" (sic.). Then it will be easier to read.

pluma• 11 years ago

Except that's now how human visual perception works. Movement is distracting and one of the main reason people hate banner ads (which historically have been extremely attention grabbing, occasionally resorting to strobing for maximum attention).

Our brains are geared for paying attention to things that move, especially things that move irregularly (like poorly looped gifs).

0942v8653• 11 years ago

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

juliangregorian2• 11 years ago

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

mpu• 11 years ago

Agreed.

hawleyal2• 11 years ago

Disagree, chuckles

javaispoo2• 11 years ago

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.

tlammens• 11 years ago

Startup time in a server is a non-issue... Those processes keep running the whole time.

javaispoo2• 11 years ago

Yeah, and memory is infinite, and all disks are free, and the computing fairies make all the processors super fast. But back in the real world, startup time is a valid concern.

sarnowski3• 11 years ago

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 ;-)

pjc50• 11 years ago

That rather proves the opposite: 6s Clojure startup time, for reasons that aren't obvious enough to be included in that blog post.

juliangregorian2• 11 years ago

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

jpfr• 11 years ago

    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).

moru00112• 11 years ago

its not "he" that's a JDK issue

ninjaroar• 11 years ago

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?

amelius• 11 years ago

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

moru00112• 11 years ago

Then its 4000 lines ..

ryanlol• 11 years ago

Which is still significantly less than with java.

ExpiredLink• 11 years ago

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

hawleyal2• 11 years ago

Database/persistence server using serialization and key-value store.

Alupis• 11 years ago

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

bradhe• 11 years ago

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.

A persistent key-value server in 40 lines and a sad fact (2014)

Related Stories