1
xuanbg 2020-03-26 11:32:39 +08:00
哪里慢了???反正我从来没觉得序列化 /反序列化是性能瓶颈
|
2
cookii 2020-03-26 11:36:16 +08:00 1
处理 json 还不就是 GSON,Fastjson,Jackson 那么几个库,你想手写吗
|
3
hantsy 2020-03-26 11:39:47 +08:00
@imzhoukunqiang 除了这些库外,现在可以用 JakartaEE 标准中 JSON-P,JSONB 解决。
|
4
guixiexiezou 2020-03-26 11:47:36 +08:00
也不算慢吧,大概处理 1 个 json 要 40ms,处理 100 个 json 要 100ms,处理 10000 个 json,要 400ms 吧。看 json 大小
|
5
chendy 2020-03-26 11:59:57 +08:00
测试了一下,Jackson
两个字符串字段,序列化每秒六百五十万次,反序列化每秒四百五十万次 二十六个字符串字段,序列化每秒一百万次,反序列化每秒四十八万次 不很快,但是通常不会是瓶颈 |
6
Aresxue 2020-03-26 12:40:08 +08:00
处理 json 从来都不是瓶颈,至于说比性能,要看谁比, 比 C++肯定不信, 但一些静态语言应该还是比得过的。
所以要想快用 C++写好, 然后通过 JNI 调用 |
7
Jooooooooo 2020-03-26 12:52:04 +08:00
超大的 String 确实是会慢的, 特别如果你用这个来打日志, 小心用
|
8
Vegetable 2020-03-26 12:59:04 +08:00
处理 JSON 本身是一个很繁重的工作啊,时间空间都是线性的,好在常用 JSON 都不会太大,很难成为业务瓶颈吧,别想太多。
|
9
Junjunya OP 业务场景是用在生成某个多个表的快照上, 两个方案,一是完全按照表的结构再建多个快照表,另一个方案就是 一个大 json 存原始表的所有数据。
Java 同事就说 json 非常耗性能,然后就推荐建表来解决这个问题。 然后我就好奇为什么非常耗性能,打算做个测试比较下 |
10
EscYezi 2020-03-26 13:36:07 +08:00 via iPhone
如果是表的快照那 json 的长度会很大。之前就遇到过从 redis 里读取一个大概有十多万个元素的 json 数组,每个元素是具有三个属性的 json 对象,然后反序列化的时候程序直接卡住了,后来想办法把 json 对象数组变成字符串数组,才能正常反序列化。
如果表中数据很多而且有多个字段,反序列化确实会成为瓶颈,不过序列化的时候倒没遇到这个问题 |