Tcl中JSON数组字符串：手动遍历vs列表命令性能差异探究

算力阿峰

2026-7-12

问题

我在SQLite中用JSON整数数组（如[5,42,14,9]）存储行排序规则，因为SQLite的json_insert只支持追加（和MySQL的json_array_insert不同），所以自己写了用户自定义函数（UDF）处理元素的插入/删除操作。

一开始我觉得把字符串截取转列表、操作再拼接（split、linsert、lreplace、join）的步骤太繁琐，就用了类似C的字符串遍历方式：通过统计逗号定位数组索引，还结合上次编辑位置优化搜索，最后拼接新字符串。但对比Tcl内置列表命令后发现，只有当编辑位置靠近上次编辑点时，手动方法更快；其他场景下，列表命令速度更快且稳定（耗时8-10ms）。

我想知道：为什么看似步骤更多的列表命令，性能反而比手动字符串遍历更好？是我的实现有问题，还是这类场景下内置列表命令本来就更高效？

附上手动遍历核心代码：

ArraySliceOptimize $addStart
if { $dir > 0 } {
  while {
         [incr i] < $len
      && [incr comma [expr {[string index $arrString $i] eq {,}}]] < $addStart } {}
  set as $i
} else {
  if { $comma == 0 } {
    set as $len
    return
  } else {
    while {
           [incr i -1] > 0
        && [incr comma -[expr {[string index $arrString $i] eq {,}}]] > 0 } {}
    set as $i
  }
}

字符串拼接代码：

append newArrayString [string range $arrString $de+1 $as-2],
append newArrayString [join $elements {,}]
append newArrayString [string range $arrString $as-1 end]

性能测试结果（单位：微秒）：

编辑位置靠近上次编辑点：手动方法1498，列表命令10220
编辑位置远离上次编辑点：手动方法31961，列表命令8761
无上次编辑位置信息：手动方法90081，列表命令8977

原因分析

内置命令的底层原生优势：Tcl的split、linsert、join等列表命令都是用C语言实现的原生代码，内存管理、字符串扫描等操作都经过了极致优化。而你的手动遍历是用Tcl解释型代码实现的，每一次string index、expr计算、循环判断都要经过解释器的额外处理，执行效率和原生编译代码不在一个量级。
手动实现的累积开销：你的手动逻辑里，循环中反复执行字符判断、索引统计这些操作，会积累大量解释器调用成本；而且string range会生成新的子字符串，多次append的拼接逻辑，也远不如内置命令直接在内存中操作元素集合高效。
数据结构的适配性差异：Tcl列表是专门为元素集合操作设计的结构，插入、删除的内部实现已经做了内存分配和元素移动的优化；而手动操作JSON字符串本质是处理线性字符序列，当编辑位置偏远或数组元素较多时，需要扫描大量字符才能定位目标，效率自然下降。
内置命令的场景预优化：针对逗号分隔数组这类常见格式，内置列表命令可能做了针对性的预优化逻辑，而你的手动实现只有在编辑位置靠近上次编辑点时，才能靠位置缓存减少扫描量，其他场景下没有通用优化加持，性能就会崩盘。

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