txiki.js REPL历史记录重复保存问题分析与解决方案

txiki.js 是一个轻量级的JavaScript运行时环境，其REPL(交互式解释器)功能为用户提供了便捷的代码测试环境。然而，近期发现该项目的REPL历史记录功能存在一个显著问题：每次启动REPL时，历史记录会以指数级增长，严重影响性能。

问题现象

当用户使用txiki.js的REPL功能时，系统会将输入的历史命令保存在SQLite数据库中。测试表明：

1. 首次启动REPL并输入3条命令后，数据库记录数为3
2. 第二次启动后，记录数变为6
3. 第三次启动后，记录数激增至12

这种指数增长模式导致两个严重问题：

1. REPL关闭速度明显变慢
2. 数据库文件迅速膨胀

问题根源

深入分析发现，问题出在历史记录的保存逻辑上。当前实现存在两个关键缺陷：

1. 重复保存：每次启动REPL时，系统会重新保存全部历史记录，而非仅新增部分
2. 低效写入：采用逐条插入方式，导致O(n)级别的fsync调用

优化方案

针对上述问题，提出了两个层次的解决方案：

短期优化：批量写入

通过使用SQLite的事务机制，将多次插入操作合并为单次事务执行：

const insert = historyDb.prepare('INSERT INTO history (entry) VALUES(?)');
const insertMany = historyDb.transaction(entries => {
  for (const str of entries) {
    insert.run(str);
  }
});
insertMany(history);

这种方法显著减少了磁盘I/O操作，提升了写入性能，但未解决数据重复的根本问题。

根本解决方案：增量保存

更彻底的修复方案是记录初始历史记录长度，仅保存新增部分：

// 启动时记录初始长度
const initialHistoryLength = history.length;

// 保存时仅处理新增记录
history.slice(initialHistoryLength).forEach(entry => {
  // 保存逻辑
});

这种方法从根本上避免了数据重复，保持了数据库的简洁性。

性能考量

在数据库操作中，频繁的小规模写入会带来显著的性能开销。特别是在REPL这种交互式环境中，用户体验对延迟非常敏感。通过批量处理和增量保存，可以：

1. 减少磁盘I/O次数
2. 降低SQLite的事务开销
3. 保持数据库文件大小合理
4. 提升REPL的响应速度

实施建议

对于希望自行修复此问题的开发者，建议：

1. 清除现有历史记录数据库
2. 应用上述优化方案
3. 重新构建项目(需执行make js命令更新捆绑代码)

这种优化不仅解决了当前问题，也为未来可能的REPL功能扩展奠定了良好的基础架构。