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

The sorry state of Java deserialization

marginalia.nu

Post reply on HN
Print view View original

11–20 of 54 posts

Re: The sorry state of Java deserialization

#11

Post by hedora »

mynegation wrote: post #5

“I admit I don’t understand these results. There’s clearly nothing in the runtime itself that prevents these types of speeds.” Oh, there is. The default Java serialization is sort of like “pickle” module in Python - if you are familiar. It will deal with pretty much anything you throw at it, figuring the data structures and offsets to serialize or parse at runtime. More efficient methods trade universality for speed,…

The article does have source code.

I don’t think any of the examples use Java’s Serializable. The first attempt reads shorts and utf8 directly from the stream.

Re: The sorry state of Java deserialization

#12

Post by marginalia_nu »

hedora wrote: post #11
mynegation wrote: post #5

“I admit I don’t understand these results. There’s clearly nothing in the runtime itself that prevents these types of speeds.” Oh, there is. The default Java serialization is sort of like “pickle” module in Python - if you are familiar. It will deal with pretty much anything you throw at it, figuring the data structures and offsets to serialize or parse at runtime. More efficient methods trade universality for speed,…

The article does have source code. I don’t think any of the examples use Java’s Serializable. The first attempt reads shorts and utf8 directly from the stream.

ObjectInputStream is one of the faster stream options tested.

Re: The sorry state of Java deserialization

#13

Post by cowwoc »

marginalia_nu wrote: post #9
antonhag wrote: post #8

Earlier quoted context omitted.

From the code samples it's hard to tell whether or not this has to do with de-serialization though. It would have been fun to see profiling results for tests such as these.

Author here, I'm away from my computer atm, but I can cook up a repo with each test in a few hours when I get home. I designed the tests as a drag race because that mimics my real world usage.

Hi,

Please add https://github.com/apache/fury to the benchmark. It claims to be a drop-in replacement for the built-in serialization mechanism so it should be easy to try.

Re: The sorry state of Java deserialization

#14

Post by marginalia_nu »

cowwoc wrote: post #13
marginalia_nu wrote: post #9

Earlier quoted context omitted.

Author here, I'm away from my computer atm, but I can cook up a repo with each test in a few hours when I get home. I designed the tests as a drag race because that mimics my real world usage.

Hi, Please add https://github.com/apache/fury to the benchmark. It claims to be a drop-in replacement for the built-in serialization mechanism so it should be easy to try.

Will do!

Re: The sorry state of Java deserialization

#15

Post by kaba0 »

mynegation wrote: post #5

“I admit I don’t understand these results. There’s clearly nothing in the runtime itself that prevents these types of speeds.” Oh, there is. The default Java serialization is sort of like “pickle” module in Python - if you are familiar. It will deal with pretty much anything you throw at it, figuring the data structures and offsets to serialize or parse at runtime. More efficient methods trade universality for speed,…

> Also, hard to say without source code but there is a high chance even more efficient methods like Protobuf create a lot of Java objects and that kills cache locality

I don’t think this can be claimed that easily without more info, generational GCs work pretty much like an arena allocator, with very good cache locality (think of an ArrayList getting filled with objects that are continuously allocated in short order. The objects will be right next to each other, in memory). If the objects are short-lived, they can be similarly cheap to stack allocation (thread-local allocation buffers that just bumping pointers).

Re: The sorry state of Java deserialization

#17

Post by garblegarble »

I know it's bad form to comment on style instead of content, but saying Smartphone enjoyers will want to switch to horizontal mode for this article due to code samples that barely fit on desktop while having the article text column shrink to less than 1/3rd of the horizontal space just feels disrespectful

Re: The sorry state of Java deserialization

#18

Post by marginalia_nu »

garblegarble wrote: post #17

I know it's bad form to comment on style instead of content, but saying Smartphone enjoyers will want to switch to horizontal mode for this article due to code samples that barely fit on desktop while having the article text column shrink to less than 1/3rd of the horizontal space just feels disrespectful

Try refresh? Should cover 60ch, but some browsers bug out when you turn for reasons i don't understand.

Re: The sorry state of Java deserialization

#19

Post by splix »

I don't think that Java serialization is designed for such a small object with just two fields. It's designed for large and complex objects. Obviously it would be slower and much larger in size that a columnar implementation designed and heavily optimized for this scenarios. It's not a fair comparison and too far from a real use case.

Try with nested objects and at least a dozen of fields across this hierarchy. And different structure for each row. It's still not a use case for Java serialization, but at least closer to what a real code would do.

Same for Protobuf, I guess. Also the JSON serialization plays the same role more or less.

Maybe something like Avro Data Files is better for a comparison with columnar formats.

Re: The sorry state of Java deserialization

#20

Post by SebastianKra »

garblegarble wrote: post #17

I know it's bad form to comment on style instead of content, but saying Smartphone enjoyers will want to switch to horizontal mode for this article due to code samples that barely fit on desktop while having the article text column shrink to less than 1/3rd of the horizontal space just feels disrespectful

Yep. I have the same frustration with GitHub and GitLab which add 3km of horizontal padding on phone screens for no reason.
Post reply on HN