您现在的位置是:网站首页> 编程资料编程资料

JavaScript中Map与Object应用场景_JavaScript_

2023-05-24 280人已围观

简介 JavaScript中Map与Object应用场景_JavaScript_

引言

在 JavaScript 中选择 Object 和 Map 的缺失指南

在 JavaScript 中,对象很方便。它们使我们能够轻松地将多条数据组合在一起。在 ES6 之后,我们为该语言添加了一个新功能 - Map. 在很多方面,它似乎比Object更强大,但界面有点笨拙。然而,大多数人在需要哈希映射时仍然会使用对象,并且只有在他们意识到键不能只是他们用例的字符串时才切换到使用。因此,在当今的 JavaScript 社区中Map仍未得到充分利用。

在这篇文章中,我将分解您应该考虑使用Mapmore 的所有原因及其性能特征与基准测试。

在 JavaScript 中,Object 是一个相当宽泛的术语。几乎所有东西都可以是一个对象,除了两种底部类型 -nullundefined. 在这篇博文中,Object 仅指普通的旧对象,由左大括号{和右大括号分隔}

博士

  • 用于Object在作者时已知的属性/字段数量固定且有限的记录,例如配置对象。以及一般一次性使用的任何东西。
  • 用于Map字典或哈希映射,其中条目数量可变,更新频繁,其键在作者时可能未知,例如事件发射器
  • 根据我的基准测试,除非键是小整数字符串,否则在插入、删除和迭代速度Map方面确实比Object高效,并且它消耗的内存Object相同大小的要少。

为什么 Object 缺少哈希映射

将对象用于哈希映射最明显的缺点可能是对象只允许字符串和符号作为键。任何其他类型都将通过toString将这些方法隐式转换为字符串。

const foo = [] const bar = {} const obj = {[foo]: 'foo', [bar]: 'bar'} console.log(obj) // {"": 'foo', [object Object]: 'bar'} 

更重要的是,将对象用于哈希映射可能会导致混淆和安全隐患。

不需要的继承

在 ES6 之前,获取哈希映射的唯一方法是创建一个空对象。

const hashMap = {} 

但是,在创建后,此对象不再为空。虽然hashMap是用一个空的对象字面量制作的,但它会自动继承自Object.prototype. 这就是为什么我们可以调用像hasOwnPropertytoStringconstructoron这样的方法,hashMap即使我们从未在对象上明确定义这些方法。

由于原型继承,我们现在混合了两种类型的属性:存在于对象本身中的属性,即它自己的属性,以及存在于原型链中的属性,即继承的属性。因此,我们需要额外的检查(例如hasOwnProperty)来确保给定的属性确实是用户提供的,而不是从原型继承的。

最重要的是,由于属性解析机制在 JavaScript 中的工作方式 Object.prototype,运行时的任何更改都会在所有对象中产生连锁反应。 这为原型污染攻击打开了大门,这对于大型 JavaScript 应用程序来说可能是一个严重的安全问题。

幸运的是,我们可以通过使用来解决这个问题Object.create(null),这会生成一个不继承任何内容的对象Object.prototype

名称冲突

当一个对象自己的属性与其原型上的属性发生名称冲突时,它会破坏预期并因此使您的程序崩溃。

例如,我们有一个foo接受对象的函数:

function foo(obj) { //... for(const key in obj) { if(obj.hasOwnProperty(key)) { } } } 

存在可靠性风险obj.hasOwnProperty(key):考虑到属性解析机制在 JavaScript 中的工作方式,如果obj包含用户提供的同名属性,则会hasOwnProperty隐藏Object.prototype.hasOwnProperty. 结果,我们不知道在运行时会准确调用哪个方法。

可以进行一些防御性编程来防止这种情况。例如,我们可以借用hasOwnProperty来代替: Object.prototype

function foo(obj) { //... for(const key in obj) { if(Object.prototype.hasOwnProperty.call(obj, key)) { // ... } } } 

一种更短的方法可能是在对象文字上调用该方法,{}.hasOwnProperty.call(key)但它仍然很麻烦。这就是为什么有一个新添加的静态方法Object.hasOwn

尺寸

Object没有提供方便的 API 来获取大小,即属性的数量。构成对象大小的因素也有细微差别:

  • 如果您只关心字符串、可枚举键,那么您可以将键转换为数组Object.keys()并获取其length.
  • 如果您想考虑不可枚举的字符串键,那么您必须使用Object.getOwnPropertyNames来获取键列表并获取其长度。
  • 如果您对符号键感兴趣,可以使用getOwnPropertySymbols来显示符号键。或者,您可以使用Reflect.ownKeys 同时获取字符串键和符号键,无论它是否可枚举。

迭代

遍历对象也有类似的复杂性。

我们可以使用良好的旧for...in循环。但它揭示了继承的可枚举属性:

Object.prototype.foo = 'bar' const obj = {id: 1} for(const key in obj) { console.log(key) // 'id', 'foo' } 

我们不能用for...of与对象一起使用,因为默认情况下它不是可迭代的,除非我们用Symbol.iterator在其上显式定义方法。

我们可以使用Object.keys,Object.valuesObject.entries来获取可枚举的字符串键(或/和值)列表,然后对其进行迭代,这会引入额外的开销步骤。

最后,臭名昭著的插入顺序没有得到充分尊重。在大多数浏览器中,整数键按升序排序并且优先于字符串键,即使字符串键插入到整数键之前也是如此。

const obj = {} obj.foo = 'first' obj[2] = 'second' obj[1] = 'last' console.log(obj) // {1: 'last', 2: 'second', foo: 'first'} 

清除

没有简单的方法可以从对象中删除所有属性,您必须使用delete操作符一个一个地删除每个属性,这在历史上被认为是缓慢的。但是我的基准测试表明,它的性能实际上比不上Map.prototype.delete

检查属性是否存在

最后,我们不能依赖点/括号符号来检查属性是否存在,因为值本身可以设置为undefined. 相反,我们必须使用Object.prototype.hasOwnProperty和 Object.hasOwn

const obj = {a: undefined} Object.hasOwn(obj, 'a') // true 

哈希映射的映射

ES6 带来了 Map。它更适合哈希映射。

首先,与Object只允许字符串和符号作为键不同,它Map支持任何数据类型的键。

但是,如果您Map用于存储对象的元数据,那么您应该使用它WeakMap来避免内存泄漏。

但更重要的是,Map它提供了用户定义和内置程序数据之间的清晰分离,但代价是额外的检索条目。

Map还提供了更好的人体工程学:Map默认情况下,A 是可迭代的。这意味着您可以使用for...of轻松迭代地图,并执行诸如使用嵌套解构从地图中提取第一个条目之类的操作。

const [[firstKey, firstValue]] = map 

Object相比Map为各种常见任务提供专用 API:

Map.prototype.has检查给定条目的存在,Object.prototype.hasOwnProperty/Object.hasOwn在对象上相比不那么尴尬

Map.prototype.get返回与提供的键关联的值。人们可能会觉得这比对象上的点表示法或括号表示法更笨拙。然而,它在用户数据和内置方法之间提供了清晰的分离。

Map.prototype.size返回 a 中的条目数,Map它显然是获得对象大小所必须执行的操作的赢家。此外,它要快得多。

Map.prototype.clear删除 a 中的所有条目,Map它比运算符delete快得多。

性能

在大多数情况下,JavaScript 社区似乎普遍认为MapObject好. 有些人声称要通过Object切换到Map.

我磨练 Leetcode 的经验似乎证实了这个信念:Leetcode 将大量数据作为测试用例提供给您的解决方案,如果您的解决方案耗时过长,它就会超时。像这样的问题只有在你使用Object时才会超时,而不是在Map.

但是,我相信只是说“Map比对象更快”是简化的。一定有一些细微差别是我想自己找出来的。所以。我构建了一个小应用程序来运行一些基准测试。

基准测试实施细节

该应用程序有一个表格,显示在ObjectMap 上测量的插入、迭代和删除速度。

插入和迭代的性能以每秒操作数来衡量。我编写了一个 util 函数measureFor,它重复运行目标函数,直到达到指定的最小时间阈值(即durationUI 上的输入字段)。它返回每秒执行此类函数的平均次数。

function measureFor(f, duration) { let iterations = 0; const now = performance.now(); let elapsed = 0; while (elapsed < duration) { f(); elapsed = performance.now() - now; iterations++; } return ((iterations / elapsed) * 1000).toFixed(4); } 

至于删除,我只是要测量使用delete运算符从对象中删除所有属性所需的时间,并将其与 Map.prototype.delete相同大小的 Map 的时间进行比较。我可以使用Map.prototype.clear,但它违背了基准测试的目的,因为我确信它会更快。

在这三个操作中,我更加关注插入,因为它往往是我在日常工作中执行的最常见的操作。对于迭代性能,很难提出一个包罗万象的基准,因为我们可以在给定对象上执行许多不同的迭代变体。这里我只测量for ... in循环。

我在这里使用了三种类型的键:

  • 字符串,例如yekwl7caqejth7aawelo4.
  • 整数字符串,例如123.
  • 由 生成的数字字符串Math.random().toString(),例如0.4024025689756525

所有的键都是随机生成的,所以我们不会碰到 V8 实现的内联缓存。我还显式地将整数和数字键转换为字符串,然后再将它们添加到对象以避免隐式转换的开销。

最后,在基准测试开始之前,还有一个至少 100 毫秒的预热阶段,我们反复创建新的对象和地图,这些新对象和地图会立即被丢弃。

如果你想玩,我把代码放在Codesandbox上。

我从100个属性/条目的Object和Map开始,一直到5000000,让每种类型的操作持续运行10000ms,看看它们彼此之间的表现如何。以下是我的发现……

为什么我们在条目数达到 5000000 时停止?

字符串键

一般来说,当键是(非数字)字符串时,在所有操作上都Map优于Object

但细微差别在于,当条目数量不是很大(低于 100000)时,Map插入速度是Object插入速度的两倍,但随着大小增长超过 100000,性能差距开始缩小。

我制作了一些图表来更好地说明我的发现。

上图显示了随着条目数量的增加(x 轴),插入率如何下降(y 轴)。但是因为 X 轴扩展得太宽(从 100 到 1000000),所以很难分辨这两条线之间的差距。

然后我使用对数刻度来处理数据并制作下面的图表。

提示: 本文由整理自网络,如有侵权请联系本站删除!
本站声明:
1、本站所有资源均来源于互联网,不保证100%完整、不提供任何技术支持;
2、本站所发布的文章以及附件仅限用于学习和研究目的;不得将用于商业或者非法用途;否则由此产生的法律后果,本站概不负责!

-六神源码网