chaokunyang

10 ms·

121.
by chaokunyang 3y ago
Those pattern are all supported in fury. And it seems fury are the only framework which implement the jdk `writeObject/readObject/writeReplace/readResolve/readObjectNoData` methods except jdk iteself. Other java serializ
122.
by chaokunyang 3y ago
Yes, on the jvm. Haven't tested it for native languages, C++/Rust should be faster since it doesn't compress data and it's zero-copy
123.
by chaokunyang 3y ago
Glad to see those great libraries. Can't wait to make fury support c#. One of the biggest difference for fury is that if support circular/shared reference and polymorphism. It's different from many other libraries.
124.
by chaokunyang 3y ago
Compared with protobuf, fury is 3.2x faster. When comparing with avro, fury is 5.3x faster. Compared with flatbuffers, fury is 4.8x faster. See https://github.com/eishay/jvm-serializers/wiki for detailed benchmark
125.
by chaokunyang 3y ago
We must realize there always a tradeoff here. If you define a dsl for serialization data and generate the code like protobuf, the security issue will be much less. But it comes with the cost. Protobuf generated class are not the domain clas
126.
by chaokunyang 3y ago
Not exactly. For java serialization, you can serialize java native object directly without define dsl and compile the schema, which are mush more easy to use. But it also means the deserialization will need to create the user-defined class,
127.
by chaokunyang 3y ago
haha, maybe it's time to use it now. It's used wisely in distributed systems at our company. I posted several blogs in our internal ata bbs, you can search it
128.
by chaokunyang 3y ago
SBE needs to define the xml for the java bean, and generated the code. It need lots of work to implement a multiple-layer nested objects serialization. So I don't added it for now.
129.
by chaokunyang 3y ago
I see, totally agreed! If any objects can be serialized, the deserialization will introduce security issue too. For example, `constructor/equals/hashCode` may contains malicious code, which introduce the deserialization risks. Fur
130.
by chaokunyang 3y ago
Yes, Game is another scenario, it's very latency sensitive. Fury is very suitable too. Actually the java implememtation has been featured by some game developers. And there has always been a demand within the community for FURY to supp
131.
by chaokunyang 3y ago
I benchmarked with Microstream using jmh and jvm-serializers data. Hare are the results: 1) fury is 43x faster for the speed. 2) Fury is 5x smaller for serialized binary size Here is the code for reproduction: https://github.com&
132.
by chaokunyang 3y ago
Protobuf/Avro doesn't support polymorphism and circular references, maybe that's one of thge reason? But even compared with protobuf, fury is 3.2x faster. When comparing with avro, fury is 5.3x faster
133.
by chaokunyang 3y ago
But I want to say that Fury will be continuously maintained. I created it 4 years ago, open sourced it in 2023.07. I've maintained it with little credits for 4 years. Now with it open-sourced, it will just make me put more efforts on i
134.
by chaokunyang 3y ago
There are too many java serialization libraries, I compared fury with jdk/kryo/fst/protostuff/protobuf/flatbuffers/thrift/msgpack/canproto/acro/jackson/json. Fury are fastest too. See
135.
by chaokunyang 3y ago
Good point! The success of a project is not only determined by what it can do, but more determined by what it chooses not to do. Only with clear and simple goals can we focus on what truly matters, while also attracting more developers to j
136.
by chaokunyang 3y ago
There are 3 kinds of scenarios are serialization bounded: 1. RPC for large microservices application, which are latency&throughput sensitive. The domain model can be huge, serialization will be the bottleneck. Some domain object graph m
137.
by chaokunyang 3y ago
See https://medium.com/@shawn.ck.yang/fury-a-blazing-fast-multi-... for fury implementation details
138.
by chaokunyang 3y ago
Fury is also the fastest jvm serialization framework in the https://github.com/eishay/jvm-serializers/wiki
139.
Fury – Fast multi-language serialization framework powered by JIT and Zero-copy(github.com)
142 points by chaokunyang 3y ago|68 comments
140.
by chaokunyang 3y ago
github pages are more complete, the website are static pages, not much work
141.
by chaokunyang 3y ago
Talked to fury JavaScript developer, he will check this later
142.
by chaokunyang 3y ago
Currently the Java and Python are production ready, and used widely in our business. JavaScript is still in early stage. The golang version are based on reflection still, we plan to do more optimization be fore release
143.
by chaokunyang 3y ago
Arrow is a columar binary format, not a serialization framework. What fury to is convert any serializable objects to binary. Fury also defined a row format which is similar to arrow binary format: https://github.com/alipay&
144.
by chaokunyang 3y ago
Fury is chosen as our project name in 2019. But when we opens sourced in 2023, we found that fury.io/fury.org domain has been taken. To keep fury naming, we have to use furyio.org