Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

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

Post reply on HN
Print view View original

11–20 of 36 posts

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

#11

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

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

#12

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

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

#13

Post by sarnowski »

pjc50 wrote: post #10
sarnowski wrote: post #7

Earlier quoted context omitted.

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

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

But its neither a Java nor JVM problem.

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

#14

Post by vidarh »

sarnowski wrote: post #8
javaispoo wrote: post #6

Earlier quoted context omitted.

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.

Don't know your "real" world. In my real world, the AWS instance takes several minutes to come up - I can spare some milliseconds on thr JVM startup.

In my real world the containers we spin up come up in seconds, but container restart is far more rare than restarting services.

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

#16

Post by moru0011 »

jpfr wrote: post #11

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 message…

its not "he" that's a JDK issue
Post reply on HN