嵌套数组遍历方案基准测试结果冲突问题及优化建议咨询

先直接拆解测试结果反转的核心原因，再给出两种方案的针对性优化方向。

一、为什么会出现性能结果反转？ #

这种跨环境的性能差异，主要和JS引擎JIT优化、内存访问模式、测试执行上下文三个因素直接相关：

1. JS引擎的JIT优化差异 #

不同环境（本地Node/浏览器 vs JSBench）的V8引擎版本或优化策略存在区别：

• 方案B大量依赖数组filter方法，这是JS引擎高度优化的内置函数，很多引擎会将其编译成接近原生的机器码，执行效率极高。
• 方案A依赖对象delete操作和Object.values转换，这些操作在部分引擎中优化程度较低——尤其是用数字作为对象key时，散列表的查找/删除缓存效率可能不如数组遍历。
• 另外，JSBench通常会重复执行测试代码，引擎的JIT编译器会对高频执行的代码路径做深度优化。方案B的逻辑更线性、代码路径简单，更容易被JIT优化；而方案A的初始化阶段（数组转对象）逻辑复杂，重复执行时会放大初始化成本。

2. 内存访问模式的影响 #

数组在内存中是连续存储的，CPU缓存命中率极高；而对象的键值对是散列存储，内存地址不连续，缓存命中率低：

• 方案B全程操作数组，在JSBench这种对缓存敏感的环境中，连续内存访问的优势被放大，抵消了迭代次数多的劣势。
• 本地环境内存通常更充裕，缓存压力小，此时方案A的O(1)查找（通过对象key直接定位season/episode）优势更明显，反而比数组遍历更快。

3. 测试执行的上下文差异 #

• 本地测试多为单次运行，方案A的初始化成本只计算一次；而JSBench是多次循环执行整个测试函数，方案A每次都要重新构建对象结构，初始化时间被重复累加，导致平均耗时上升。
• 方案B的初始化仅做简单对象拷贝，每次循环的初始化成本极低，多次运行后平均耗时反而更低。

二、两种方案的优化建议 #

方案A优化：减少不必要拷贝，优化结构转换 #

方案A的核心优势是O(1)查找，但初始化时的深拷贝和多次结构转换是性能瓶颈，优化后如下：

// 用Map建立索引，仅存引用不深拷贝原数据
const showIndex = new Map();
for (const show of shows) {
  const seasonMap = new Map();
  for (const seasonData of show.seasons) {
    const episodeSet = new Set();
    // 存入该季所有episode编号，方便快速判断
    for (const ep of seasonData.season.episodes) {
      episodeSet.add(ep.episode_number);
    }
    seasonMap.set(seasonData.season.season_number, {
      seasonData,
      episodeSet
    });
  }
  showIndex.set(show.id, { show, seasonMap });
}

// 处理已观看记录，直接从Set中删除对应episode
for (const watched of watchedShows) {
  const showEntry = showIndex.get(watched.showId);
  if (!showEntry) continue;
  const seasonEntry = showEntry.seasonMap.get(watched.season);
  if (!seasonEntry) continue;
  seasonEntry.episodeSet.delete(watched.episode);
}

// 基于原结构生成最终结果，减少转换开销
const unwatchedShows = [];
for (const { show, seasonMap } of showIndex.values()) {
  const filteredSeasons = [];
  for (const { seasonData, episodeSet } of seasonMap.values()) {
    if (episodeSet.size === 0) continue; // 整季已看，过滤
    const filteredEpisodes = seasonData.season.episodes.filter(ep => episodeSet.has(ep.episode_number));
    filteredSeasons.push({
      ...seasonData,
      season: {
        ...seasonData.season,
        episodes: filteredEpisodes
      }
    });
  }
  if (filteredSeasons.length === 0) continue; // 整剧已看，过滤
  unwatchedShows.push({
    ...show,
    seasons: filteredSeasons
  });
}

优化点：

• 用Map和Set替代普通对象，避免数字key的散列开销，Set的delete和has操作均为O(1)。
• 初始化仅存引用和索引，不深拷贝原数据，节省内存和初始化时间。
• 最终生成结果时直接基于原结构过滤，减少不必要的Object.values转换。

方案B优化：提前构建已观看索引，避免重复遍历 #

方案B的核心问题是每次处理watchedShow时都要遍历整个seasons数组，优化后如下：

// 先构建已观看记录的索引结构
const watchedIndex = new Map();
for (const item of watchedShows) {
  if (!watchedIndex.has(item.showId)) {
    watchedIndex.set(item.showId, new Map());
  }
  const seasonMap = watchedIndex.get(item.showId);
  if (!seasonMap.has(item.season)) {
    seasonMap.set(item.season, new Set());
  }
  seasonMap.get(item.season).add(item.episode);
}

// 批量过滤shows，避免重复遍历
const unwatchedShows = shows.reduce((acc, show) => {
  const seasonMap = watchedIndex.get(show.id);
  if (!seasonMap) {
    acc.push(show);
    return acc;
  }
  const filteredSeasons = show.seasons.reduce((seasonAcc, seasonData) => {
    const episodeSet = seasonMap.get(seasonData.season.season_number);
    if (!episodeSet) {
      seasonAcc.push(seasonData);
      return seasonAcc;
    }
    const filteredEpisodes = seasonData.season.episodes.filter(ep => !episodeSet.has(ep.episode_number));
    if (filteredEpisodes.length > 0) {
      seasonAcc.push({
        ...seasonData,
        season: {
          ...seasonData.season,
          episodes: filteredEpisodes
        }
      });
    }
    return seasonAcc;
  }, []);
  if (filteredSeasons.length > 0) {
    acc.push({ ...show, seasons: filteredSeasons });
  }
  return acc;
}, []);

优化点：

• 把watchedShows转成showId -> season -> Set<episode>的索引结构，后续查找已观看剧集的时间复杂度从O(n)降到O(1)。
• 用reduce替代多次filter和循环，减少数组中间变量的创建，降低内存开销。
• 避免了原方案中每次遍历watchedShows时都要遍历seasons数组的重复操作，大幅减少迭代次数。

三、最终推荐 #

如果你的场景中watchedShows数量远大于shows数量，推荐使用优化后的方案A；如果shows数量更大，或者需要更好的跨环境稳定性，推荐优化后的方案B——它逻辑直观，且在大多数JS引擎中能获得稳定的优化效果。

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