I am working on a project where Java's native serialization is slow, so we want to move to implementing Externalize interface on the classes for superior performance.
However, these classes have lots of data members, and we have realized its easy to make mistakes while writing these two methods. We are just reading/writing all of the members of the class in these functions, nothing fancy. Is there some way of generating the readExternal() writeExternal() blocks for externalize automatically in an offline process, or at compile time?
I had a look at http://projectlombok.org/, and something like that would have been ideal.
Similarly, we would like to keep these classes immutable, but immutable classes can not implement the externalizable interface - we want to use the proxy class pattern from effective java - having that generated would be useful too.
I am working on a project where Java's native serialization is slow
How slow? Why? Making it faster with lots of hand coding is most unlikely to be either economically feasible or maintainable in the long run. Serialization overheads should really come down to time and space bounds in transmisssion. There's no particular reason why Java's default serialziation should be startlingly slower than the result of all the hand coding you are planning. You would be better off investigating causes. You might find for example that a well-placed BufferedOutputStream would solve all your problems.
Regarding Project Lombok it's rejected the feature.
I'd consider leveraging alternative frameworks:
SBE - for financial transactions;
kryo project - for Java compatibility;
FlatBuffers - for lazy zero copy parsing and ability to skip nested structures;
Protobuf - bit more compact than flat buffers but missing parsing in random access regions (possible in flat buffers e.g. on memory mapped files).
Java serialisation is very inefficient both throughput, size, portability, and schema migration.
MapStruct - can be good option to map something mutable into immutable if required with minimum custom code (and IDE support).
Related
I was wondering how the serialization of MicroStream works in detail.
Since it is described as "Super-Fast" it has to rely on code-generation, right? Or is it based on reflections?
How would it perform in comparison to the Protobuf-Serialization, which relies on Code-generation that directly reads out of the java-fields and writes them into a bytebuffer and vice-versa.
Using reflections would drastically decrease the performance when serializing objects on a huge scale, wouldn't it?
I'm looking for a fast way to transmit and persist objects for a multiplayer-game and every millisecond counts. :)
Thanks in advance!
PS: Since I don't have enough reputation, I can not create the "microstream"-tag. https://microstream.one/
I am the lead developer of MicroStream.
(This is not an alias account. I really just created it. I'm reading on StackOverflow for 10 years or so but never had a reason to create an account. Until now.)
On every initialization, MicroStream analyzes the current runtime's versions of all required entity and value type classes and derives optimized metadata from them.
The same is done when encountering a class at runtime that was unknown so far.
The analysis is done per reflection, but since it is only done once for every handled class, the reflection performance cost is negligible.
The actual storing and loading or serialization and deserialization is done via optimized framework code based on the created metadata.
If a class layout changes, the type analysis creates a mapping from the field layout that the class' instances are stored in to that of the current class.
Automatically if possible (unambiguous changes or via some configurable heuristics), otherwise via a user-provided mapping. Performance stays the same since the JVM does not care if it (simplified speaking) copies a loaded value #3 to position #3 or to position #5. It's all in the metadata.
ByteBuffers are used, more precisely direct ByteBuffers, but only as an anchor for off-heap memory to work on via direct "Unsafe" low-level operations. If you are not familiar with "Unsafe" operations, a short and simple notion is: "It's as direct and fast as C++ code.". You can do anything you want very fast and close to memory, but you are also responsible for everything. For more details, google "sun.misc.Unsafe".
No code is generated. No byte code hacking, tacit replacement of instances by proxies or similar monkey business is used. On the technical level, it's just a Java library (including "Unsafe" usage), but with a lot of properly devised logic.
As a side note: reflection is not as slow as it is commonly considered to be. Not any more. It was, but it has been optimized pretty much in some past Java version(s?).
It's only slow if every operation has to do all the class analysis, field lookups, etc. anew (which an awful lot of frameworks seem to do because they are just badly written). If the fields are collected (set accessible, etc.) once and then cached, reflection is actually surprisingly fast.
Regarding the comparison to Protobuf-Serialization:
I can't say anything specific about it since I haven't used Protocol Buffers and I don't know how it works internally.
As usual with complex technologies, a truly meaningful comparison might be pretty difficult to do since different technologies have different optimization priorities and limitations.
Most serialization approaches give up referential consistency but only store "data" (i.e. if two objects reference a third, deserialization will create TWO instances of that third object.
Like this: A->C<-B ==serialization==> A->C1 B->C2.
This basically breaks/ruins/destroys object graphs and makes serialization of cyclic graphs impossible, since it creates and endlessly cascading replication. See JSON serialization, for example. Funny stuff.)
Even Brian Goetz' draft for a Java "Serialization 2.0" includes that limitation (see "Limitations" at http://cr.openjdk.java.net/~briangoetz/amber/serialization.html) (and another one which breaks the separation of concerns).
MicroStream does not have that limitation. It handles arbitrary object graphs properly without ruining their references.
Keeping referential consistency intact is by far not "trying to do too much", as he writes. It is "doing it properly". One just has to know how to do it properly. And it even is rather trivial if done correctly.
So, depending on how many limitations Protobuf-Serialization has ("pacts with the devil"), it might be hardly or even not at all comparable to MicroStream in general.
Of course, you can always create some performance comparison tests for your particular requirements and see which technology suits you best. Just make sure you are aware of the limitations a certain technology imposes on you (ruined referential consistency, forbidden types, required annotations, required default constructor / getters / setters, etc.).
MicroStream has none*.
(*) within reason: Serializing/storing system-internals (e.g. Thread) or non-entities (like lambdas or proxy instances) is, while technically possible, intentionally excluded.
We're looking for a high performance compact serialization solution for Java objects on GAE.
Native Java serialization doesn't perform all that well and it's terrible at compatibility i.e. it can't unserialize an old object if a field is added to the class or removed.
We tried Kryo which performs well in other environments and supports back compatibility when fields are added, but unfortunately the GAE SecurityManager slows it down terribly by adding a check to every method call in the recursion. I'm concerned that might be the issue with all serialization libraries.
Any ideas please? Thanks!
Beware, premature optimisation is the root of all evil.
You should first try one of the standard solutions and then decide if it fits your performance requirements. I did test several serialization solutions on GAE (java serialisation, JSON, JSON+ZIP) and they were an order of magnitude faster than datastore access.
So if serialising data takes 10ms and writing it to datastore takes 100ms, there is very little added benefit in trying to optimise the 10ms.
Btw, did you try Jackson?
Also, all API calls on GAE are implemented as RPC calls to other servers, where payload is serialised as protobuf.
Do you need cross-language ability? and re. high-performance are you referring to speed only, or including optimized memory management for less GC, or including serialized object size?
If you need cross-language I think Google's protobuf is a solution. However, it can hardly be called "high performance" because the UTF-8 strings created on Java side causes constant GCs.
In case the data you are supporting is mostly simple objects and you don't need composition, I would recommend you to write your own serialization layer (not kidding).
Using an enum to index your fields so you can serialize fields that contains value only
Create maps for primitive types using trove4j collections.
Using cached ByteBuffer objects if you could predict size for most of your objects to be under a certain value.
Using string dictionary to reduce string object re-creation and use cached StringBuilder during deserialization
That's what we did for our "high-performance" java serialization layer. Essentially we could achieve almost object-less serialization/de-serialization on a reasonably good timing.
Background
There is a well-known tool called Wireshark. I've been using it for ages. It is great, but performance is the problem. Common usage scenario includes several data preparation steps in order to extract a data subset to be analyzed later. Without that step it takes minutes to do filtering (with big traces Wireshark is next to unusable).
The actual idea is to create a better solution, fast, parallel and efficient, to be used as a data aggregator/storage.
Requirements
The actual requirement is to use all power provided by modern hardware. I should say there is a room for different types of optimization and I hope I did a good job on upper layers, but technology is the main question right now. According to the current design there are several flavors of packet decoders (dissectors):
interactive decoders: decoding logic can be easily changed in runtime. Such approach can be quite useful for protocol developers -- decoding speed is not that critical, but flexibility and fast results are more important
embeddable decoders: can be used as a library.This type is supposed to have good performance and be flexible enough to use all available CPUs and cores
decoders as a service: can be accessed through a clean API. This type should provide best of the breed performance and efficiency
Results
My current solution is JVM-based decoders. The actual idea is to reuse the code, eliminate porting, etc, but still have good efficiency.
Interactive decoders: implemented on Groovy
Embeddable decoders: implemented on Java
Decoders as a service: Tomcat + optimizations + embeddable decoders wrapped into a servlet (binary in, XML out)
Problems to be solved
Groovy provides way to much power and everything, but lucks expressiveness in this particular case
Decoding protocol into a tree structure is a dead end -- too many resources are simply wasted
Memory consumption is somewhat hard to control. I did several optimizations but still not happy with profiling results
Tomcat with various bells and whistles still introduces to much overhead (mainly connection handling)
Am I doing right using JVM everywhere? Do you see any other good and elegant way to achieve the initial goal: get easy-to-write highly scalable and efficient protocol decoders?
The protocol, format of the results, etc are not fixed.
I've found several possible improvements:
Interactive decoders
Groovy expressiveness can be greatly improved, by extending Groovy syntax using
AST Transformations. So it would be possible to simplify decoders authoring still providing good performance. AST (stands for Abstract Syntax Tree) is a compile-time technique.
When the Groovy compiler compiles Groovy scripts and classes, at some
point in the process, the source code will end up being represented in
memory in the form of a Concrete Syntax Tree, then transformed into an
Abstract Syntax Tree. The purpose of AST Transformations is to let
developers hook into the compilation process to be able to modify the
AST before it is turned into bytecode that will be run by the JVM.
I do not want to reinvent the wheel introducing yet another language to define/describe a protocol structure (it is enough to have ASN.1). The idea is to simplify decoders development in order to provide some fast prototyping technique. Basically, some kind of DSL is to be introduced.
Further reading
Embeddable decoders
Java can introduce some additional overhead. There are several libraries to address that issue:
HPPC
Trove
Javolution
Commons-primitives
Frankly speaking I do not see any other option except Java for this layer.
Decoders as a service
No Java is needed on this layer. Finally I have a good option to go but price is quite high. GWan looks really good.
Some additional porting will be required, but it is definitely worth it.
This problem seems to share the same characteristic of many high-performance I/O implementation problems, which is that the number of memory copies dominates performance. The scatter-gather interface patterns for asynchronous I/O follow from this principle. With scatter-gather, blocks of memory are operated on in place. As long as the protocol decoders take block streams as input rather than byte streams, you'll have eliminated a lot of the performance overhead of moving memory around to preserve the byte stream abstraction. The byte stream is a very good abstraction for saving engineering time, but not so good for high-performance I/O.
In a related issue, I'd beware of the JVM just because of the basic type String. I can't say I'm familiar with how String is implemented in the JVM, but I do imagine that there's not a way of making a string out of a block list without doing a memory copy. On the other hand, a native kind of string that could, and which interoperated with the JVM String compatibly could be a way of splitting the difference.
The other aspect of this problem that seems relevant is that of formal languages. In the spirit of not copying blocks of memory, you also don't want to be scanning the same block of memory over and over. Since you want to make run-time changes, that means you probably don't want to use a precompiled state machine, but rather a recursive descent parser that can dispatch to an appropriate protocol interpreter at each level of descent. There are some complications involved when an outer layer does not specify the type of an inner layer. Those complications are worse when you don't even get the length of the inner content, since then you're relying on the inner content to be well formed to prevent runaway. Nevertheless, it's worth putting some attention into understand how many times a single block will be scanned.
Network traffic is growing (some analytics), so there will be a need to process more and more data per second.
The only way to achieve that is to use more CPU power, but CPU frequency is stable. Only number of cores is growing. It looks like the only way is to use available cores more efficiently and scale better.
I am working in a highly distributed environment. A lot of network access and a lot of db access.
I have some classes that are send over and over the network, and are serialized and de-serialized.
Most of the classes are quite simple in their nature, like :
class A{
long a;
long b;
}
And some are more complex (Compound - Collections).
There are some people in the company I work that claim that all the classes should implement Externalizable rather than Serializable , and that would make a major impact on the performance of the application.
Although the impact on the performance is very difficult to measure, since the application is so big and so distributed and not fully ready, I can't really simulate a full load right now.
So maybe some of you know some interesting article that would reveal anything to me. Or maybe you can share some thoughts.
My basic intuition was that is would not make any difference serializing and deserializing simple classes (like the one above) over the network/db, lets say when the IO process of the whole app are around 10%. ( I mean 90% of the time the system is doing other stuff than IO )
My basic intuition was that is would not make any difference serializing and deserializing simple classes (like the one above) over the network/db, lets say when the IO process of the whole app are around 10%. ( I mean 90% of the time the system is doing other stuff than IO )
Your intuition sounds reasonable. But what exactly is taking 10% of the time? Is it just the serialization / deserialization? Or does the 10% include the real (clock) time to do the I/O?
EDIT
If you have actual profiling measurements to back up your "10% to 15%" clock time doing serialization + deserialization + I/O, then logic tells you that the maximum performance improvement you can get will be less than that. If you can separate the I/O from the serialization / deserialization, you can refine that upper bound. My guess is that the actual improvement will be less than 5%.
I suggest that you create a small benchmark to send and receive one of your data types using serialization and externalization and see what percentage difference it actually makes.
It must be said that there is a (relatively) significant overhead in generic serialization versus optimally implemented externalization. A lot of this due to the general properties of serialization.
There is the overhead of marshaling / unmarshaling the type descriptors for each class used in the object being transmitted.
There is the overhead of adding each marshaled object to a hash table so that the serialization faithfully records cycles, etc.
However, serialization / deserialization is only a small part of the total I/O overheads, and these are only a small part of your application.
This is a pretty good website comparing many different Java serialization mechanisms.
http://github.com/eishay/jvm-serializers/wiki
I would ask them to come up with some measurements to support their claims. Then everybody will have a basis for a rational discussion. At present you don't have one. Note that it is those with the claims that should produce the supporting evidence: don't get sucked into being responsible for proving them wrong.
Java serialization is flexible and standard, but its not designed to be fast, especially for simple objects. If you want speed I suggest you try hessian or protobuf. These can be 5x faster for simple objects. Or youc an write a custom serializer which can be as much as 10x faster.
For us, custom serialization is the way to go. We let Java do what it does well, or at least good enough, for free, and provide custom support for what it does badly. This is a lot less code than full Externalizable support.
I can't imagine in what case custom serialization couldn't be done but using Externalizable could (referring to Roman's comment on Peter L's answer). Specifically, I'm referring to, e.g., implementation of writeObject/readObject.
Generic serialization can be fast
see http://java-is-the-new-c.blogspot.de/2013/10/still-using-externalizable-to-get.html
It depends on your concrete system if serialization performance is significant. I have seen systems which gained a lot of performance by speeding up serialization. It's not only about CPU but also about latencies. E.g. if a distributed system does a lot of blocking request/responses (requestor waiting for result), serializations adds up to overall request response time which can be significant as its (1) encode request (2) decode request (3) encode response (4) decode response. So 4 (de-)serialization's happing per request/response
If you had the chance to significantly change/update Java's classpath libraries, which things would you add/update/change/deprecate/remove?
Restructure all the various aspects of the currently far to monolithic class library into seperate modules with lower interdependencies. This would require to seperate interfaces and provided default implementations into distinctive class hierachies (similar to what exists for the SAX API already). Rationale: allow deployments with stripped down class libraries and additionally enable third party replacementes and extensions of certain central aspects (crypto, network protocols, i18n, ...).
Redesign all collection classes and some of the java.lang classes into much smaller building blocks that can be assembled into more flexible and more powerfull data structures (along the philosophy of the Google Collections classes). This would offer far more context independant behavioural interfaces, like i.e. CharSequence or Comparable.
Provide more platform specific (Extension-)APIs and implementations that cover as much as is reasonable of the supported platforms (and grow with them) and accept that code that is using these classes will not be portable without extra effort from the developer. This is meant to allow the creation of non trivial software that is able to compete with native software in terms of usability, usefullness and general perceived quality. These APIs would for example allow access to block devices, vt100 terminals, the Windows registry etc.
Redesign Swing in a multilayered way (i.e. controls on top of basic building blocks on top of a graphics primitives API) and make it far more polymorphic. I.e a single Action interface with a single method perform instead of lots of special Listener interfaces. Additionally I'd offer a wrapper framework that encapsulates native GUI components (in the spirit of my previous proposal).
Try to find a better way to handle security related access restrictions for sandbox environments that doesn't limit the overall flexibilty of many imporatant fundamental classes. Currently language features originaly intended for design purposes are heavily abused for security purposes which has led to rather static and nonpolymorphic classes and APIs because they could be expoited from within a sandbox if they were more open (and the approach still failed to be secure enough many many times).
Provide a less naive serialization system that supports weak references, has error detection and supports class evolution.
I'd add CheckedException at the same level as RuntimeException (make it less often that people "have" to catch Exception)
I'd remove all the deprecated APIs.
I'd remove the old collection classes, like Vector and Dictionary.
I'd make a boat load of exception classes under IOException.
I'd replace as many public static final int X; constants as I could with enums.
I'd get rid of Object.hashCode and define a Hashable / Hasher interfaces instead. (But I'd retain System.identityHashCode(Object) because despite its overheads it does something very useful that is impossible to do any other way.)
I'd get rid of Object.equals and define an Equatable / Equater interfaces instead. (But with better names if I could manage it.)
I'd get rid of Object.clone. I might retain it as a method on the array classes.
I'd get rid of Object.finalize and replace it with something that naive C/C++ programmers won't notice until they are experienced enough to know that finalization is almost always the wrong solution.
I'd get rid of System.gc();
I'd replace the clunky global System.in/out/err stuff with something that used Readers/PrintWriters and that was / could easily be "scoped" by thread or threadgroup.
I'd remove the ability to take a primitive lock on any Object (... OK not strictly library change).
I'd try figure out how to implement safe versions of thread.stop/suspend/resume ... even if this meant implementing Isolates in J2SE JVMs.