Yet another attempt at typed JS data

Claude Pache claude.pache at gmail.com
Wed Feb 12 11:51:37 UTC 2020


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.giammarchi at 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 <ljharb at gmail.com <mailto:ljharb at 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.giammarchi at gmail.com <mailto:andrea.giammarchi at 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 <ljharb at gmail.com <mailto:ljharb at 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 <kaizhu256 at gmail.com <mailto:kaizhu256 at 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.giammarchi at gmail.com <mailto:andrea.giammarchi at 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 at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20200212/66a65504/attachment-0001.html>


More information about the es-discuss mailing list