650939 - Investigate Array, TypedArray performance issues in noVNC tests

Status: NEW

(Core :: JavaScript Engine, defect)

Description

[David Humphrey (:humph)]

Here's an interesting post, with tests, showing performance of using Arrays and TypedArrays in the noVNC project:

http://blog.n01se.net/?p=248

In it, the author finds that Firefox suffers from speed issues with random reads, perhaps a regression in the 4 time frame.

The tests are at https://github.com/kanaka/noVNC/blob/master/tests/arrays.html

Comment 1

[Tom S [:evilpie]]

So the test loop is this:
for (cnt = 0; cnt < conf.read_cnt; cnt++) {
    i = (arr[i] + cnt) % arraySize;
}
If i change the mod to and and the time drops from 828 (5000000 reads / 1000000 array size) to 247.

Comment 2

[Tom S [:evilpie]]

*an and (&)

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is a tracer issue; if I disable the tracer then the problem more or less goes away.

Comment 4

[Boris Zbarsky [:bzbarsky]]

And so far I have not managed to reproduce this in the shell....

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Totally non-minimal shell testcase which does NOT show the problem

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Minimal HTML testcase using the same script which _does_ show the problem.

Comment 7

[Boris Zbarsky [:bzbarsky]]

For what it's worth, I can't reproduce the "normal" array thing in browser either.

But for typed arrays I see us spending a ton of time under js::GetPropertyByName and js_NumberToStringWithBase.

Obvious guess is that we somehow end up with 'i' being a double; the question is _why_.  And why it only happens in browser....

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: What looks like a minimal shell testcase; must be run with -m -j

I might have been using just -j for the other shell testcase...

This testcase shows the problem when run with -m -j (as well as -m -j -p -a), but NOT with just -j or just -m.  Furthermore, it stops showing the problem if the typed array sequential read test is removed.  It stops showing the problem if the "normal" array random read test is removed or moved to after the typed array random read test. 

I hope someone who understands things like the oracle better than I can make sense of this...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Interestingly, the type inference branch doesn't seem to have this problem, even if I just run |-m -j -p -a| or |-m -j| (i.e. without -n).  If I toss in -n, the behavior is identical to just -m except a bit faster (not nearly as fast as -j on either branch, though).

Brian, any idea what changes on the TI branch might be affects -m -j without -n?

Comment 10

[Jan de Mooij [:jandem]]

JM typed array IC's are disabled on the TI branch (also without -n), see bug 643842.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Aha!  Let me go look at those; I bet they produce doubles for integer typed arrays or something.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Hmm.  Except LoadFromTypedArray seems to tell masm that these are integers...  And disabling typed array ICs locally in my TM tree does not make the problem go away.

Comment 13

[Tom S [:evilpie]]

This just came up on HN again. http://news.ycombinator.com/item?id=4246967 (http://blog.varunkumar.me/2012/07/binary-data-processing-in-javascript.html)

Comment 14

[Reece H. Dunn]

There is a note at the end of the blog saying that when the generic function is replaced with one for each array type the performance improved significantly.

Thus, firefox is not instantiating a specialization of each function call. What should happen ideally is that if the type inference oracle (JM and/or Ion version) knows all the types of a function, it should create a specialization for that function using that information (remembering which specializations it has).