Julia无分配构建字符串方案问询：WebSocket传输场景性能优化

1 修复原代码的基础问题 #

• 原函数引用了jumps、string_of_id、type_of_speller三个全局变量，全局变量类型不稳定会带来额外性能开销和冗余分配，首先需要把这些变量改为函数入参，消除全局依赖。
• 原代码存在大量多余的string()嵌套调用，Julia的string()原生支持多参数直接拼接，不需要给每个变量单独套一层string()，多余调用会产生无意义的临时字符串，增加分配次数。
• 原函数定义的入参px、ticker、ordType没有被使用，可根据实际需求保留或删除，避免无用参数带来的开销。
• 原手动拼接逻辑的引号转义存在错误，实际运行生成的JSON格式不符合规范，容易导致下游解析失败。

2 预分配内存优化方案（手动拼接场景） #

如果需要坚持手动拼接字符串，可以使用IOBuffer提前预分配足够容量的缓冲区，所有内容写入缓冲区后再一次性转为字符串，可大幅减少分配次数：

function stringConcat(side::String, sz::Int64, jumps::Float64, string_of_id::String, speller::String)
    # 预分配足够大的缓冲区，可根据实际最大字符串长度调整sizehint数值
    io = IOBuffer(sizehint=256)
    write(io, "{\"id\":\"", string(abs(rand(Int64))), "\",\"message\":[{\"Key1\":", string(rand(1:10000)), ",\"Leftorright\":\"", side, 
          "\",\"numjump\":", string(jumps), ",\"jumpid\":\"", string_of_id, "\",\"sz\":", string(sz), ",\"speller\":\"", speller,
          "\",\"mode\":\"json\"}],\"operation\":\"jumping\"}")
    return String(take!(io))
end

该方案可将分配次数降到2~3次，耗时可降到100ns以内。

3 生产环境更推荐方案：使用专门的JSON序列化库 #

手动拼接JSON极易出现转义错误、格式问题，且性能上限不如专门的序列化库。推荐使用JSON3.jl的轻量化序列化能力，配合结构体可实现极低的分配开销：

using JSON3

# 提前定义消息结构体，编译期即可确定序列化格式，无额外运行时开销
struct MessageItem
    Key1::Int
    Leftorright::String
    numjump::Float64
    jumpid::String
    sz::Int
    speller::String
    mode::String
end

struct WSMessage
    id::String
    message::Vector{MessageItem}
    operation::String
end

function stringConcat(side::String, sz::Int64, jumps::Float64, string_of_id::String, speller::String)
    msg = WSMessage(
        string(abs(rand(Int64))),
        [MessageItem(rand(1:10000), side, jumps, string_of_id, sz, speller, "json")],
        "jumping"
    )
    return JSON3.write(msg)
end

该方案除了JSON序列化本身的必要分配外，无额外冗余分配，格式正确性有保障，适配WebSocket的发送要求。

额外优化技巧 #

• 如果发送的JSON格式固定，可提前把不变的常量部分缓存下来，运行时只替换可变字段的内容，进一步减少计算开销。
• 如果需要更低的延迟，可直接把内容写入WebSocket的IO流，不需要先转成完整的String再发送，省去一次内存拷贝。

内容的提问来源于stack exchange，提问作者user3376601