You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

为何Rust中serde_json反序列化无标签枚举速度慢?

无标签枚举与serde_json::Value反序列化性能差异分析

测试代码

#![allow(unused)]
use serde::{Deserialize, Serialize};
use std::collections::HashMap;

use std::time::Instant;

#[derive(Serialize, Deserialize, Debug, Clone, PartialEq)]
#[serde(untagged)]
enum NumberOrString {
    String(String),
    Int(i64),
    Float(f64),
}

fn main() {
    let json_str = r#"{
        "17594136111": [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499],
        "0000000017704043101": ["5", "7"],
        "features": ["a1"]
    }"#;

    let start_time = Instant::now();
    let parsed: HashMap<&str, Vec<serde_json::Value>> = serde_json::from_str(json_str).expect("panicking !!! ");
    println!("Elapsed time: {:.2?}", start_time.elapsed());

    let start_time = Instant::now();
    let parsed2: HashMap<&str, Vec<NumberOrString>> = serde_json::from_str(json_str).expect("panicking !!! ");
    println!("Elapsed time: {:.2?}", start_time.elapsed());
}

运行结果

$ cargo run 
Compiling rust_tutorial v0.1.0 (/Users/sandeep.yadav/code/codetest/rust/rust_tutorial)
Finished dev [unoptimized + debuginfo] target(s) in 2.26s
Running `target/debug/rust_tutorial`
Elapsed time: 360.78µs
Elapsed time: 2.22ms

$ cargo run --release
Compiling rust_tutorial v0.1.0 (/Users/sandeep.yadav/code/codetest/rust/rust_tutorial)
Finished release [optimized] target(s) in 2.47s
Running `target/release/rust_tutorial`
Elapsed time: 74.82µs
Elapsed time: 439.90µs

$ cargo run --release
Finished release [optimized] target(s) in 0.03s
Running `target/release/rust_tutorial`
Elapsed time: 63.13µs
Elapsed time: 354.89µs

核心疑问

  • 为何无标签枚举的反序列化速度比包含更多类型(Null、Bool、List、Object等)的serde_json::Value慢至少5倍?
  • 明明自定义枚举的可选值范围更小,该现象的原因是什么?
  • 有哪些可实现相同效果的替代方案?

原因分析

1. 无标签枚举的重试匹配逻辑

serde处理无标签枚举时,会严格按照枚举变体的定义顺序依次尝试反序列化:先尝试将JSON值解析为String,失败后回退并尝试Int,再失败才尝试Float。这种重试逻辑在处理大量元素(比如测试用例中近500个整数)时,每个元素都要经历一次失败的字符串解析,再进入整数解析,额外开销被大幅放大。

而serde_json::Value是直接根据JSON的原始类型一次性匹配到对应变体,不需要任何重试,解析路径更直接。

2. 原生类型的底层优化

serde_json::Value是serde_json库的原生类型,底层直接与JSON解析器的内部结构对接,解析逻辑经过高度优化,没有额外的泛型调度或枚举分支判断开销。

而自定义无标签枚举的反序列化代码是serde通过宏自动生成的,生成的代码包含大量条件判断和错误处理分支,尤其是类型不匹配时的回退逻辑,这些额外逻辑在批量解析场景下会累积出明显的性能差距。

3. 类型判断的额外成本

对于测试用例中的整数元素,serde_json::Value直接识别为Number::Int并存储;而自定义枚举需要先执行字符串解析的逻辑(包括字符检查、内存分配尝试),失败后再触发整数解析,每个元素都多了一次无效的类型尝试,进一步拉低了整体性能。

替代方案

1. 手动实现自定义反序列化逻辑

跳过serde自动生成的重试逻辑,直接在Deserialize trait的实现中根据JSON原始类型匹配枚举变体,避免多次尝试。示例代码如下:

use serde::{de, Deserialize, Deserializer};
use std::fmt;

#[derive(Debug, Clone, PartialEq)]
enum NumberOrString {
    String(String),
    Int(i64),
    Float(f64),
}

impl<'de> Deserialize<'de> for NumberOrString {
    fn deserialize<D>(deserializer: D) -> Result<Self, D::Error>
    where
        D: Deserializer<'de>,
    {
        struct NumberOrStringVisitor;

        impl<'de> de::Visitor<'de> for NumberOrStringVisitor {
            type Value = NumberOrString;

            fn expecting(&self, formatter: &mut fmt::Formatter) -> fmt::Result {
                formatter.write_str("a string or a number")
            }

            fn visit_str<E>(self, v: &str) -> Result<Self::Value, E>
            where
                E: de::Error,
            {
                Ok(NumberOrString::String(v.to_string()))
            }

            fn visit_string<E>(self, v: String) -> Result<Self::Value, E>
            where
                E: de::Error,
            {
                Ok(NumberOrString::String(v))
            }

            fn visit_i64<E>(self, v: i64) -> Result<Self::Value, E>
            where
                E: de::Error,
            {
                Ok(NumberOrString::Int(v))
            }

            fn visit_f64<E>(self, v: f64) -> Result<Self::Value, E>
            where
                E: de::Error,
            {
                Ok(NumberOrString::Float(v))
            }
        }

        deserializer.deserialize_any(NumberOrStringVisitor)
    }
}

这种实现方式直接根据JSON类型调用对应的处理方法,没有重试逻辑,性能可以接近serde_json::Value。

2. 使用有标签枚举(若JSON结构允许)

如果JSON数据可以添加类型标签(例如{"type": "int", "value": 123}),serde可以直接根据标签匹配对应的枚举变体,完全避免重试,性能会大幅提升。

3. 针对固定类型字段单独处理

如果提前知道某个字段的类型(比如测试用例中的"17594136111"字段全是整数),可以直接将该字段反序列化为Vec<i64>,而不是通用枚举,彻底消除类型判断的开销。

4. 选择高性能JSON解析库

例如simd-json这类针对性能优化的库,在处理大量数据时能提供比serde_json更优的解析速度,配合自定义类型使用可以进一步提升性能。


内容的提问来源于stack exchange,提问作者Sandeep Yadav

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.08.21 23:18:22