JavaScript多键海量数据存储性能优化解析及最优方案咨询

Hey there! Let's break down your question step by step, since you're working with a dataset uniquely identified by three keys (i, j, z) and noticed a big performance gap between two storage approaches in Chrome.

First, let's restate your performance test code for clarity:

Test Code 1: Nested Object Approach #

console.time('global1');
var global1 = {};
for (var i = 0; i < 100; ++i) {
  for (var j = 0; j < 100; ++j) {
    for (var z = 0; z < 100; ++z) {
      global1[i] = global1[i] || {};
      global1[i][j] = global1[i][j] || {};
      global1[i][j][z] = { a: 123456789 };
    }
  }
}
console.timeEnd('global1');

Test Code 2: Combined Array Key Approach #

console.time('global2');
var global2 = {};
for (var i = 0; i < 100; ++i) {
  for (var j = 0; j < 100; ++j) {
    for (var z = 0; z < 100; ++z) {
      global2[[i,j,z]] = { a: 123456789 };
    }
  }
}
console.timeEnd('global2');

Why is the first code faster in Chrome? #

The key difference comes down to unnecessary runtime overhead in the second approach:

• JavaScript object keys can only be strings or Symbols. When you use [i,j,z] as a key, the engine automatically converts the array to a string via toString(), which produces a comma-separated string like "0,0,0". This conversion happens 1,000,000 times (100×100×100) in your loops—each conversion adds small but cumulative overhead.
• The nested object approach uses direct property access. Once you create the nested i and j objects, accessing global1[i][j][z] is just a series of fast memory lookups. Chrome's V8 engine is heavily optimized for this hierarchical object access, with caching and direct memory addressing that avoids extra computation.

What kind of performance optimization is this? #

This falls under two related optimization categories:

• Avoiding implicit type conversions: You're eliminating the automatic array-to-string conversion that adds runtime cost.
• Leveraging engine-optimized access patterns: Using nested objects takes advantage of V8's optimized property lookup system, which is tuned for direct, hierarchical object access.

Best ways to store this (or larger) datasets #

The optimal approach depends on your dataset size and use case:

• Small to medium datasets (1M entries or fewer): The nested object approach is great—it's fast, readable, and requires no extra libraries. For even better performance, you can pre-initialize the nested objects instead of using || {} checks (though V8 optimizes the || pattern pretty well already).
• Large datasets (1M+ entries):
  • Use a Map with a pre-computed unique key: Instead of relying on implicit array conversion, manually create a string key (e.g., ${i}-${j}-${z}) or encode the three values into a single number (e.g., BigInt(i) * 1000000n + BigInt(j) * 1000n + BigInt(z)). Map has better performance for dynamic key sets than plain objects in some cases.
  • Binary storage: If your data has a fixed structure (like the {a: number} in your example), use TypedArray or ArrayBuffer to store values in binary form. This reduces memory overhead and allows for ultra-fast access.
  • Specialized storage (Node.js/backend): For extremely large datasets, use a key-value database like LevelDB or a columnar store, which are designed to handle high-volume keyed data efficiently.
• Edge case: Immutable keys: If your keys are known upfront, pre-initialize the entire nested object structure before populating it to eliminate the global1[i] = global1[i] || {} checks entirely.

内容的提问来源于stack exchange，提问作者i.Nemiro