Yet another attempt at typed JS data

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Feb 12 13:22:39 UTC 2020


That indeed worked:

```
V8 version 8.2.34
d8> %DebugPrint(Array.from(Array(2), (_, i) => i));
DebugPrint: 0x1c67080c5ddd: [JSArray]
 - map: 0x1c67082817f1 <Map(PACKED_SMI_ELEMENTS)> [FastProperties]
 - prototype: 0x1c6708248f7d <JSArray[0]>
 - elements: 0x1c67080c5ded <FixedArray[4]> [PACKED_SMI_ELEMENTS]
 - length: 2
 - properties: 0x1c67080406e9 <FixedArray[0]> {
    #length: 0x1c67081c0165 <AccessorInfo> (const accessor descriptor)
 }
 - elements: 0x1c67080c5ded <FixedArray[4]> {
           0: 0
           1: 1
         2-3: 0x1c6708040385 <the_hole>
 }
0x1c67082817f1: [Map]
 - type: JS_ARRAY_TYPE
 - instance size: 16
 - inobject properties: 0
 - elements kind: PACKED_SMI_ELEMENTS
 - unused property fields: 0
 - enum length: invalid
 - back pointer: 0x1c670804030d <undefined>
 - prototype_validity cell: 0x1c67081c0451 <Cell value= 1>
 - instance descriptors #1: 0x1c6708249605 <DescriptorArray[1]>
 - transitions #1: 0x1c6708249621 <TransitionArray[4]>Transition array #1:
     0x1c6708042e91 <Symbol: (elements_transition_symbol)>: (transition to
HOLEY_SMI_ELEMENTS) -> 0x1c6708281869 <Map(HOLEY_SMI_ELEMENTS)>

 - prototype: 0x1c6708248f7d <JSArray[0]>
 - constructor: 0x1c6708248e51 <JSFunction Array (sfi = 0x1c67081cbf85)>
 - dependent code: 0x1c67080401ed <Other heap object
(WEAK_FIXED_ARRAY_TYPE)>
 - construction counter: 0

[0, 1]
```

> It could maybe be a conceivable argument for introducing
`Array.createAsNonSparse(2)`.

My proposal basically boils down, if we don't like the `TypedArray`
concept, to this:

```js
Array.createAsNonSparse(
  length, // pre-defined length of the Array
  optionalValueOrCallback // values per each entry
);

Array.createAsNonSparse(3, 0); // [0, 0, 0] non sparsed
Array.createAsNonSparse(3, i => i * i); // [0, 1, 4] non sparsed
```

Would this makes more sense? It'd be super handy in many cases, as many
developers don't even know what is a holey/sparsed Array, neither how to
*not* create one.

If the second argument is too ambiguous, I wouldn't mind having it as
function all the time:

```js
Array.createAsNonSparse(3); // [undefined, undefined, undefined] non sparsed
Array.createAsNonSparse(3, () => 0); // [0, 0, 0] non sparsed
Array.createAsNonSparse(3, i => i * i); // [0, 1, 4] non sparsed
```

Thanks.



On Wed, Feb 12, 2020 at 12:51 PM Claude Pache <claude.pache at gmail.com>
wrote:

> 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> 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> 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> 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> 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> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> 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/770c12ac/attachment.html>


More information about the es-discuss mailing list