At some point in the algorithm of [Array.from], the newly-created array will indeed be created as sparse (at steps 9/10), but this is usually not observable (that is, unless you are creating an instance of a subclass of Array with very unusual behaviour) as far as the spec is concerned (optimisation is not part of the spec).
If it is important for you to circumvent the v8 limitation in its optimisation process, you should be able to write `Array.from(Array(2), _ => undefined)`: the array will be created as non-sparse at steps 5.a/b. In any case, this optimisation detail is by very far not a satisfactory argument for introducing the heavy feature you proposed. It could maybe be a conceivable argument for introducing `Array.createAsNonSparse(2)`. [Array.from]: https://tc39.es/ecma262/#sec-array.from —Claude > Le 12 févr. 2020 à 10:23, Andrea Giammarchi <andrea.giammar...@gmail.com> a > écrit : > > Which part of `HOLEY_SMI_ELEMENTS` makes you think so? > > V8 version 8.2.34 > d8> %DebugPrint(Array.from({length: 2}, (_, i) => i)) > DebugPrint: 0x5ab080c5ded: [JSArray] > - map: 0x05ab08281869 <Map(HOLEY_SMI_ELEMENTS)> [FastProperties] > - prototype: 0x05ab08248f7d <JSArray[0]> > - elements: 0x05ab080c5dfd <FixedArray[2]> [HOLEY_SMI_ELEMENTS] > - length: 2 > - properties: 0x05ab080406e9 <FixedArray[0]> { > #length: 0x05ab081c0165 <AccessorInfo> (const accessor descriptor) > } > - elements: 0x05ab080c5dfd <FixedArray[2]> { > 0: 0 > 1: 1 > } > 0x5ab08281869: [Map] > - type: JS_ARRAY_TYPE > - instance size: 16 > - inobject properties: 0 > - elements kind: HOLEY_SMI_ELEMENTS > - unused property fields: 0 > - enum length: invalid > - back pointer: 0x05ab082817f1 <Map(PACKED_SMI_ELEMENTS)> > - prototype_validity cell: 0x05ab081c0451 <Cell value= 1> > - instance descriptors #1: 0x05ab08249605 <DescriptorArray[1]> > - transitions #1: 0x05ab08249639 <TransitionArray[4]>Transition array #1: > 0x05ab08042e91 <Symbol: (elements_transition_symbol)>: (transition to > PACKED_DOUBLE_ELEMENTS) -> 0x05ab08281891 <Map(PACKED_DOUBLE_ELEMENTS)> > > - prototype: 0x05ab08248f7d <JSArray[0]> > - constructor: 0x05ab08248e51 <JSFunction Array (sfi = 0x5ab081cbf85)> > - dependent code: 0x05ab080401ed <Other heap object (WEAK_FIXED_ARRAY_TYPE)> > - construction counter: 0 > > [0, 1] > > On Wed, Feb 12, 2020 at 7:01 AM Jordan Harband <ljh...@gmail.com > <mailto:ljh...@gmail.com>> wrote: > No, `Array.from` never produces a holey array whatsoever; only ever a dense > array. > > On Sun, Feb 9, 2020 at 11:08 PM Andrea Giammarchi > <andrea.giammar...@gmail.com <mailto:andrea.giammar...@gmail.com>> wrote: > Unfortunately, `Array.from({ length: 4 }, () => whatever)` produces a holey > array, so that the `.repeat(...)` idea, if capable of packing elements in a > better way, wouldn't be so terrible, as simplification. > > Although, the intent of this proposal was to also grant "shapes" or kindness > of each entry, same way typed Arrays do, but maybe that would require some > better primitive, as in `const Shape = Object.defineShape(...)` and > `Object.createShape(Shape)` or similar. > > On Sun, Feb 9, 2020 at 10:01 PM Jordan Harband <ljh...@gmail.com > <mailto:ljh...@gmail.com>> wrote: > That already exists - `Array.from({ length: 4 }, () => whatever)` - I assume > that the hope is to have an array where it is *impossible* for it to have the > wrong "kind" of data, and a userland factory function wouldn't provide that. > > On Sun, Feb 9, 2020 at 10:39 AM kai zhu <kaizhu...@gmail.com > <mailto:kaizhu...@gmail.com>> wrote: > > It's a bit of a mess to create an Array that is not holed and gets best > > optimizations [1], and this proposal would like to address that exact case. > > could the performance issue be resolved more easily with a simple > static-function `Array.repeat(<length>, <repeater>)`? > > ```js > let structuredList; > structuredList = Array.repeat(4, function (ii) { > return { > index: 2 * ii + 1, > tags: [] > }); > /* > structuredList = [ > { index: 1, tags: [] }, > { index: 3, tags: [] }, > { index: 5, tags: [] }, > { index: 7, tags: [] } > ]; > */ > ``` > > the only time i can practically enforce the shape of a "StructuredArray" is > during element-insertion, > and a userland insertion/creation function would be just as effective as a > StructuredArray constructor. > > enforcing shapes during element deletions and updates are going to be hard > and likely just as confusing with StructuredArray as they are with regular > Array. > > also note that most javascript arrays need to be easily JSON-serialized for > message-passing > over-the-wire (commonly http) to external systems. > > -kai > > On Sat, Feb 8, 2020 at 3:46 AM Andrea Giammarchi <andrea.giammar...@gmail.com > <mailto:andrea.giammar...@gmail.com>> wrote: > > having to retroactively add checks like... > > we already have typed arrays in JS so I don't think this would be any > different > > > I _think_ that moderns virtual machines already did these optimisations > > despite there isn't a TypedArray like that. > > It's a bit of a mess to create an Array that is not holed and gets best > optimizations [1], and this proposal would like to address that exact case. > > [1] https://v8.dev/blog/elements-kinds <https://v8.dev/blog/elements-kinds> > > > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
