Wouldn't Array(5).fill(0).map(fn) too?
-
-
Replying to @WebReflection @matteocollina
Yep. AFAIK the only way to avoid elem kind transitions and holes is: const createArray = (len, v) => { if (!len) return []; const a = [v]; // make arr have correct elem kind while (--len) a.push(v); return a; }
2 replies 0 retweets 3 likes -
Replying to @Zbjorn @matteocollina
cc'ing
@mathias here, is that really the only way to avoid holed arrays? It seems like, in an explicit intent from the devs to provide hints to the engine, a possible bug to file in v81 reply 0 retweets 0 likes -
Yep, https://v8.dev/blog/elements-kinds … is still correct. It’s not a bug; `new Array(len)` (and `Array(len)`) pre-allocate a sufficiently large backing store, which is beneficial in case of large, extremely sparse arrays.
3 replies 0 retweets 1 like -
so, basically all I had to do in order to have PACKED_(XXX_)?ELEMENTS back was to add a `.map($ => $)` after creation
const createArray = (length, fn) => Array.from(
typeof length === 'number' ? {length} : length,
typeof fn === 'function' ? fn : () => fn
).map($ => $);1 reply 0 retweets 4 likes -
Replying to @WebReflection @mathias and
meaning: every Array .fill(value) should be followed by an identity map in order to have fastest v8 Array optimizations: Array(3).fill(0); // HOLEY_SMI_ELEMENTS Array(3).fill(0).map($ => $); // PACKED_SMI_ELEMENTS now you know (and one more time I miss a Function.identity)
1 reply 0 retweets 4 likes -
That's a very expensive way to get to the end goal (about 70x slower than what I suggested). Would have to have a*ton* of array accesses for the packed optimizations to make up for that.
1 reply 0 retweets 1 like -
Not sure I follow ...most answered to my initial tweet "I'd rather use .fill(...)" to which I've replied "if it's packed array you're after, add a .map(identity) after fill". I think fill should promote the array as packed and not holey, the name itself kinda implies that
1 reply 0 retweets 0 likes -
1 reply 0 retweets 1 like
-
thanks for the pointer, although you mentioned earlier this wasn't a bug, hence I didn't bother filing/searching. It'd be great if that bug gets resolved this year, `Array(length).fill(kind)` looks like the best pattern to create non holey Array with a pre-allocated size
1 reply 0 retweets 0 likes
It’s not a bug — this is more like a feature request. Holey arrays never go back to being non-holey; the issue is asking for an exception to that behavior.
-
-
I don't have enough background knowledge here to understand why arrays can get promoted only in one direction, but fair enough ...it's just weird developers would need user-land libraries to create faster arrays, with a way slower creation time, stuff likehttps://github.com/WebReflection/packed-array#readme …
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
JavaScript, HTML, CSS, HTTP, performance, security, Bash, Unicode, i18n, macOS.