Fixed-length untyped arrays

Jordan Harband ljharb at gmail.com
Sat Dec 22 05:14:13 UTC 2018


Is there any evidence that existing arrays *prevent* engines from making
optimizations? I believe (and any implementors, please correct me if I'm
wrong) that the most common approach is to guess the likely maximum size
for the array, double it, and then allocate that much memory - and thus all
the array methods can remain optimized until the memory size needs to
double again.

On Fri, Dec 21, 2018 at 6:52 PM Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> Usually, the native resizable array is good enough. But sometimes, you
> don't want to resize it, just allocate a slab of memory for objects.
> Typed arrays already implement this for integers, but I find it quite
> often in certain applications that I want to do this for arbitrary
> objects, too. So how about a `FixedArray` analogue to `TypedArray`
> that implements most the same stuff `TypedArray` does, just without
> the binary data integration or numeric coercion?
>
> There's a few other benefits to having a native fixed-size untyped array:
>
> 1. Engines can make major assumptions about allocation and use that to
> improve performance and minimize allocations - notably, they can
> choose to allocate the array's entries in the object itself, since it
> can't change for the lifetime of that object. This is the norm in some
> languages, like Rust.
> 2. Engines can optimize things like `.map`, `.filter`, `.concat`, and
> similar far more easily. Those don't have to be generic, and since
> they can assume everything's contiguous, it's much easier to
> implement.
> 3. Engines can make guarantees about allocation size, and that's the
> whole point of this proposal. These objects only require a minimum of
> type info, GC info, its length, and `length` number of machine
> pointers.
>
> Of course, yes, normal arrays *could* provide most of these, but
> consider how V8 internally uses an `InternalArray` extensively to
> implement many JS built-ins in JS and its CodeStubAssembler DSL. It's
> also worth noting V8 didn't start inlining `Array.prototype.map` and
> friends for dense arrays until it figured out how to bail out of a
> JIT-compiled loop from within that loop with negligible overhead (it
> took an internal redesign), and no other engine I'm aware of performs
> this optimization, either - it's all because JS's resizable arrays can
> also be sparse.
>
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
> _______________________________________________
> 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/20181221/f0624e97/attachment.html>


More information about the es-discuss mailing list