Array.prototype.remove(item)

Isiah Meadows isiahmeadows at gmail.com
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 farsightsoftware.com> wrote:
> On Fri, Nov 10, 2017 at 10:38 AM, Isiah Meadows <isiahmeadows at gmail.com>
> 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,
repeatedly.

>
> 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:

https://github.com/MithrilJS/mithril.js/pull/1949/files#diff-000bdfae56251b0715111d2b18c9de3cL579

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

https://github.com/MithrilJS/mithril.js/blob/next/render/render.js#L164-L255

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):

https://github.com/isiahmeadows/enigma/blob/master/src/scanner/string.ts#L240-L282
https://github.com/isiahmeadows/enigma/blob/master/src/scanner/seek.ts

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 isiahmeadows.com

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


More information about the es-discuss mailing list