| 17:40 | <ljharb> | hey implementer folks. i've got someone in another venue raving about how sparse arrays aren't bad and slow etc (which defies what i understand to be decades of best practice around avoiding them). i want to know whatever the modern truth is, and it'd be awesome if someone from each of the browsers could describe the perf characteristics of creating/accessing/mutating a sparse array in their engine, or ideally, point me to a blog post or something that explains them? |
| 20:36 | <snek> | they aren't as evil as they used to be like 10 years ago, in V8 at least, but they're still very much off the happy path, and you'll take a hit in performance for using them. |
| 20:52 | <ljharb> | one of the arguments was that accessing elements was fast even if creation was slower |
| 21:20 | <snek> | hmm, you could say its fast in that the optimizer doesn't completely bail out for holey arrays, like they may have tended to do back in the day. but if an array is represented as holey that brings in some unavoidable overhead. around 15-20% compared to the same non-holey representation when i last benchmarked it. these things are much more granular these days though. it really comes down to like each "operation" (e.g. field accesss, methods, etc) and what things someone wrote out as optimizations for it. |
| 21:23 | <snek> | this still looks pretty accurate to me https://v8.dev/blog/elements-kinds, though i'm a bit behind on some of the more recent changes in v8 regarding the turboshaft rewrite. |