On 10/30/2014 06:14 AM, Adrian Perez de Castro wrote:
> On Thu, 30 Oct 2014 09:29:36 +0100, Florian Bösch <pyalot at gmail.com> wrote:
>
>> The usecases:
>>
>> [...]
>>
>> *3) Initializing an existing array with a repeated numerical value*
>>
>> For audio processing, physics and a range of other tasks it's important to
>> initialize an array with the same data.
>>
>> for(var i=0; i<size; i++){ someArray[i] = 0; }
> For this use case there is %TypedArray%.prototype.fill(), see:
>
>   http://people.mozilla.org/~jorendorff/es6-draft.html#sec-%typedarray%.prototype.fill
>
> JavaScript engines are expected to implement it at some point. For example
> I am implementing this in V8, along with other new typed array methods. The
> engines should be able to generate quite good code for uses of this function
> and/or provide optimized versions relying on knowledge of the underlying
> element type of the typed array they are applied to.

I implemented this for Firefox 2 years ago, but never landed it -
https://bugzilla.mozilla.org/show_bug.cgi?id=730880

Now there is %TypedArray%.prototype.fill. But I've become generally
skeptical about it as an answer to performance concerns. I would rather
see engines hyperoptimize

  for(var i=0; i<size; i++){ someArray[i] = 0; }

based on observed type information. Which is not to say that we wouldn't
want to make TA#fill fast too, but the above seems more generally useful.

On a related note, I *would* like to have some way of getting the OS to
decommit memory. See https://bugzilla.mozilla.org/show_bug.cgi?id=855669
(start reading at about comment 22) for our discussion and attempt at
this, which looks like it mysteriously trailed off this last March.
Theoretically, the above loop could also trigger a decommit, but I think
it's too much to expect the engine to guess when that's going to be a
good idea. On the other hand, from a spec POV it's unobservable
behavior, which makes it weird.

On 10/30/2014 06:14 AM, Adrian Perez de Castro wrote:

> For this use case there is %TypedArray%.prototype.fill(), see:
>
>   http://people.mozilla.org/~jorendorff/es6-draft.html#sec-%typedarray%.prototype.fill
>
> JavaScript engines are expected to implement it at some point. For example
> I am implementing this in V8, along with other new typed array methods. The
> engines should be able to generate quite good code for uses of this function
> and/or provide optimized versions relying on knowledge of the underlying
> element type of the typed array they are applied to.

I implemented this for Firefox 2 years ago, but never landed it -
https://bugzilla.mozilla.org/show_bug.cgi?id=730880

Now there is %TypedArray%.prototype.fill. But I've become generally
skeptical about it as an answer to performance concerns. I would rather
see engines hyperoptimize

```js
for(var i=0; i<size; i++){ someArray[i] = 0; }
```

based on observed type information. Which is not to say that we wouldn't
want to make TA#fill fast too, but the above seems more generally useful.

On a related note, I *would* like to have some way of getting the OS to
decommit memory. See https://bugzilla.mozilla.org/show_bug.cgi?id=855669
(start reading at about comment 22) for our discussion and attempt at
this, which looks like it mysteriously trailed off this last March.
Theoretically, the above loop could also trigger a decommit, but I think
it's too much to expect the engine to guess when that's going to be a
good idea. On the other hand, from a spec POV it's unobservable
behavior, which makes it weird.