doc[protocol]: update document

This commit is contained in:
godotg committed 2023-10-28 09:22:14 +08:00
1 parent 6d0dc5168f
commit 9ca8dc424d
2 files changed
+6 -8

No files matched your search

+3 -5
View File
@@ -53,13 +53,11 @@ memory:64g
- Use Javassist bytecode to enhance the dynamic generation of serialization and deserialization functions for sequential - Use Javassist bytecode to enhance the dynamic generation of serialization and deserialization functions for sequential
execution, and sequential functions can be easily JIT compiled to achieve extreme performance execution, and sequential functions can be easily JIT compiled to achieve extreme performance
- Natively integrated with netty's high-performance Byte Buf - Natively integrated with netty's high-performance ByteBuf, support Zero Copy
- With primitive type collection, there is no boxing and unboxing, invalid GCs are avoided, and the performance is fast - With primitive type collection, there is no boxing and unboxing, invalid GCs are avoided, and the performance is fast
enough enough
- Inherently thread-safe and lock-free; kryo forces each thread to have its own instance of Kryo, which is a heavy - thread-safe and lock-free, without any performance loss in multi-threaded environment
design, especially in scenarios with many threads - No reflection, no unsafe operations, support GraalVM
- No reflections, no unsafe operation; The use of objenesis in Kryo resulted in a lot of unsafe, and warnings when
running in Java 11
- Flattening the call depth of the method stack, and there is no performance penalty for nesting data structures, such - Flattening the call depth of the method stack, and there is no performance penalty for nesting data structures, such
as List<Set<Map<>>>; Comparing kryo and protobuf data structure nesting results in a performance penalty as List<Set<Map<>>>; Comparing kryo and protobuf data structure nesting results in a performance penalty
- There is no risk of vulnerability injection, only bytecode enhancement will be performed during initialization, and no - There is no risk of vulnerability injection, only bytecode enhancement will be performed during initialization, and no
+3 -3
View File
@@ -45,10 +45,10 @@ cpu: i9900k
### Ⅳ. 为什么快 ### Ⅳ. 为什么快
- 使用Javassist字节码增强动态生成顺序执行的序列化和反序列化函数,顺序化的函数可以轻易的被JIT编译以达到极致的性能 - 使用Javassist字节码增强动态生成顺序执行的序列化和反序列化函数,顺序化的函数可以轻易的被JIT编译以达到极致的性能
- 原生集成netty的高性能ByteBuf - 原生集成netty的高性能ByteBuf,支持Zero Copy
- 使用primitive type collection,没有装箱和拆箱,避免了无效GC,性能也足够快 - 使用primitive type collection,没有装箱和拆箱,避免了无效GC,性能也足够快
- 天生线程安全并且无锁化;kryo强制要求每条线程都有自己的一个Kryo实例,这是一个比较重的设计,特别是线程比较多的场景 - 天生线程安全并且无锁化,多线程环境无任何性能损失
- 没有反射,没有unsafe操作;对比kryo中使用objenesis导致大量unsafe,而且在Java11中运行会出现警告 - 没有反射,没有unsafe操作,只是GraalVM
- 扁平化了方法栈的调用深度,数据结构嵌套没有任何性能损失,如List<Set<Map<>>>;对比kryo和protobuf数据结构嵌套会出现性能损失 - 扁平化了方法栈的调用深度,数据结构嵌套没有任何性能损失,如List<Set<Map<>>>;对比kryo和protobuf数据结构嵌套会出现性能损失
- 无漏洞注入风险,只有初始化时会进行字节码增强,后期不会再进行任何字节码的操作 - 无漏洞注入风险,只有初始化时会进行字节码增强,后期不会再进行任何字节码的操作
- 充分利用程序局部性原理,序列化器放在short[]数组中,对象序列化和反序列化只会查找一次序列化器 - 充分利用程序局部性原理,序列化器放在short[]数组中,对象序列化和反序列化只会查找一次序列化器