与缓存 SVG 数据相比，从磁盘读取 SVG 图标文件？答案

【问题标题】：reading SVG icon files from disk compared to caching the SVG data?与缓存 SVG 数据相比，从磁盘读取 SVG 图标文件？
【发布时间】：2020-07-26 16:41:14
【问题描述】：

我有一个使用d3 的Electron 应用程序，它使用了许多小的（50 x 50 像素）SVG 图标——可能有 100 个或更多，并且有很多重复。

使用fs 从磁盘读取图标并返回到我的d3 创建例程。用户可以在编辑项目时切换图标。他们可以反复使用一个或两个图标，或者使用可供他们选择的 50 个图标中的任何一个。

我以为我很聪明，写了一个“图标管理器”，它将被fs读取后的SVG数据缓存在一个数组中，这样如果图标被多次使用，“内存中”版本可以被返回，而不是再次从磁盘读取。

我一年多前编写了代码，今天不得不去解决一个问题。现在看它，我想这一切都是愚蠢的：与遍历数组相比，fs 访问磁盘是一种毫无意义甚至可能是“负面”的优化——随着数组中项目数量的增加， “成本”越来越高。

我是不是无缘无故在这里工作太辛苦了？

const fs = require('fs');
const iconLib = [];

exports.getIcon = function (iconName, iconPath) {

    for (let i = 0; i < iconLib.length; i++) {
        if (iconLib[i].iconName == iconName) {
            return iconLib[i].iconData;
        }
    }

    if (fs.existsSync(iconPath)) {
        let data = fs.readFileSync(iconPath, 'utf8');
        iconLib.push({ iconName: iconName, iconData: data })
        return data;
    } else {
        // TODO return something useful
        return 0;
    }
};

【问题讨论】：

我投票结束这个问题，因为这更适合Code Review。

标签： javascript node.js d3.js electron fs

【解决方案1】：

不是每次检索都必须遍历的数组，不如使用 JavaScript 的内置 Map？

向地图添加图标：

    const iconMap = new Map();

    function cacheIcon(iconName, iconData) {
      iconMap.set(iconName, iconData);
    }

从地图中检索图标：

    iconData = iconMap.get(iconName);

【讨论】：

谢谢，我之前没用过Map——看起来很有用。然而，它似乎在做我所拥有的。从您链接到的文档中 A Map 对象按插入顺序迭代其元素 - for...of 循环为每次迭代返回一个 [key, value] 数组。 - 所以仍然存在步行通过阵列——与每次需要 SVG 时从磁盘读取相比。这就是我想知道的。我对其进行了计时，其中一个 SVG 的 fs 磁盘读取平均约为 0.5 毫秒。我想我“聪明”地编写了一些“聪明”的愚蠢代码。
Map 是可迭代的，但从 Map 中检索元素不需要迭代。另一方面，在数组中查找元素总是需要迭代。使用 Map 检索比通过数组搜索要快得多，