简体   繁体   中英

Golang vs JavaScript (v8/node.js) map performance

Out of curiosity I wrote some trivial benchmarks comparing the performance of golang maps to JavaScript (v8/node.js) objects used as maps and am surprised at their relative performance. JavaScript objects appear to perform roughly twice as fast as go maps (even including some minor performance edges for go)!

Here is the go implementation:

// map.go
package main
import "fmt"
import "time"
func elapsedMillis(t0, t1 time.Time) float64 {
  n0, n1 := float64(t0.UnixNano()), float64(t1.UnixNano())
  return (n1 - n0) / 1e6
}
func main() {
  m := make(map[int]int, 1000000)
  t0 := time.Now()
  for i := 0; i < 1000000; i++ {
    m[i] = i     // Put.
    _ = m[i] + 1 // Get, use, discard.
  }
  t1 := time.Now()
  fmt.Printf("go: %fms\n", elapsedMillis(t0, t1))
}

And here is the JavaScript:

#!/usr/bin/env node
// map.js
function elapsedMillis(hrtime0, hrtime1) {
  var n0 = hrtime0[0] * 1e9 + hrtime0[1];
  var n1 = hrtime1[0] * 1e9 + hrtime1[1];
  return (n1 - n0) / 1e6;
}
var m = {};
var t0 = process.hrtime();
for (var i=0; i<1000000; i++) {
  m[i] = i; // Put.
  var _ = m[i] + 1; // Get, use, discard.
}
var t1 = process.hrtime();
console.log('js: ' + elapsedMillis(t0, t1) + 'ms');

Note that the go implementation has a couple of minor potential performance edges in that:

  1. Go is mapping integers to integers directly, whereas JavaScript will convert the integer keys to string property names.

  2. Go makes its map with initial capacity equal to the benchmark size, whereas JavaScript is growing from its default capacity).

However, despite the potential performance benefits listed above the go map usage seems to perform at about half the rate of the JavaScript object map! For example (representative):

go: 128.318976ms
js: 48.18517ms

Am I doing something obviously wrong with go maps or somehow comparing apples to oranges?

I would have expected go maps to perform at least as well - if not better than JavaScript objects as maps. Is this just a sign of go's immaturity (1.4 on darwin/amd64) or does it represent some fundamental difference between the two language data structures that I'm missing?

[Update]

Note that if you explicitly use string keys (eg via s := strconv.Itoa(i) and var s = ''+i in Go and JavaScript, respectively) then their performance is roughly equivalent.

My guess is that the very high performance from v8 is related to a specific optimization in that runtime for objects whose keys are consecutive integers (eg by substituting an array implementation instead of a hashtable).

I'm voting to close since there is likely nothing to see here...

Your benchmark is synthetic a bit, just like any benchmarks are. Just for curious try

for i := 0; i < 1000000; i += 9 {

in Go implementation. You may be surprised.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM