Isiah Meadows isiahmeadows at
Fri Nov 10 14:17:48 UTC 2017

Inline. (Hindsight, should've included this in the previous email)

On Fri, Nov 10, 2017 at 5:57 AM, T.J. Crowder
<tj.crowder at> wrote:
> On Fri, Nov 10, 2017 at 10:38 AM, Isiah Meadows <isiahmeadows at>
> wrote:
>> My proposal is this: add a new `Array.prototype.remove(item)` method...
> So not just a "would be nice," but you've provided a concrete reason for
> putting it in the standard lib: Providing an optimized version vs. what can
> be done in userland. Excellent. :-)

Oh, and engines could totally use SIMD vectorization in this routine
for dense, homogenous integer, float, or non-numeric arrays, and they
could just emit raw machine code for it. In the case of a first-item
`remove` with integers or objects, you could search N at a time until
you find the first occurrence, then from there, do an overlapping
`memmove` (which is a good candidate for raw assembly optimization),
and then just chop the last entry off. In the case of a multi-item
`removeAll`, you could just do that first step, search N at a time,

> In a similar vein, is there a specific reason you're modifying the array in
> place vs. creating a new one via `filter`? Memory churn? Callback cost
> (though that's *amazingly* low in modern implementations as I'm sure you
> know)? Lots of independent references to it? Are any/all things you've had a
> real-world problem with around this? (That's a question, not veiled
> criticism.)

As stated before, it's in lower-level, more performance-sensitive
code. In these cases, memory churn is a very real thing you have to
contend with, and in some cases, the allocation of an array or object
is itself a potential problem. In nearly every virtual DOM library, in
most , the core involves

If you want to see a case where simply fixing type checking and
reducing event handler allocation (including multiple C++ round-trips)
basically doubled performance in a particular common case in a
benchmark, check this diff out:

If you want to see a case where every branch, every function call has
to be carefully monitored, check this out:

If you want to see another case where I've run into issues with
branching and *string* allocation (in the former) - strings aren't as
cheap as you might expect in a number-heavy context - check this out
(pardon the TypeScript):

It happens, just not on a regular basis with application-level code.
Kind of like `Array.prototype.copyWithin` - it's a case where in
theory, you could do it in-language, but the engine could do it
*immensely* faster.

> FWIW, if it removes all occurrences of the items, I'd call it `removeAll`.
> For some reason -- I'm not exactly sure why -- I'd expect `remove` to remove
> only the first. Perhaps because `indexOf`/`findIndex` finds only the first
> index, `find` finds only the first match, etc.? And it leaves the door open
> for a `remove` that doesn't remove all (though that seems hard to justify if
> a minimalist standard lib prevails). Web safety of the name would need
> checking in any case. (Quick check says neither MooTools nor Prototype adds
> either `remove` or `removeAll` to `Array.prototype`.)
> -- T.J. Crowder


Isiah Meadows
me at

Looking for web consulting? Or a new website?
Send me an email and we can get started.

More information about the es-discuss mailing list