Project: v8 Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 2022 new Float64Array() very slow
Starred by 7 users Reported by rob...@kineticgm.com, Mar 23 2012 Back to list
Status: Available
Owner: ----
Cc:
HW: ----
OS: ----
Priority: 2
Type: Bug



Sign in to add a comment
It's about 10x as long as new Array() with the same size (eg. size 6).

Also, this crashed:

numeric.test4 = function test4(n,m){
var zzz= mkAV(n);
var t1= new Date();
for(m=m;m>0;m--) new Float64Array(n*n);
var t2 = new Date();
alert(t2-t1);}

numeric.test4(600,100000);
 
For the sake of reproducibility, could you clarify how mkAV is defined? Thanks!

You can use this, i.e. without that line:

numeric.test4 = function test4(n,m){
var t1= new Date();
for(m=m;m>0;m--) new Float64Array(n*n);
var t2 = new Date();
alert(t2-t1);} 

Also, the crash and the slowness of new Float64Array() creation might be separate issues, but they might be related to a common problem in the Float64Array initialization.
Capture.JPG
10.5 KB View Download
Comment 3 by u...@chromium.org, Apr 5 2012
Cc: kbr@chromium.org jkummerow@chromium.org
This CL https://chromiumcodereview.appspot.com/9835055/ fixes the issue for d8.

We need to land a similar change in WebKit bindings:
- call V8::AdjustAmountOfExternalAllocatedMemory(allocated_size) whenever a new buffer is allocated for a typed array.
- call V8::AdjustAmountOfExternalAllocatedMemory(-allocated_size) whenever a buffer is freed.

Ken, do you know what would be the best place for these calls in WebKit?

Comment 4 by kbr@chromium.org, Apr 5 2012
Cc: jam...@chromium.org dslomov@chromium.org
Actually, there's a very old bug jamesr filed about that a long time ago: https://bugs.webkit.org/show_bug.cgi?id=42912

The problem with his original patch is that certain typed array instances are created on other threads than the main thread (in particular, by the Web Audio API's worker threads), and the calls to AdjustAmountOfExternalAllocatedMemory were causing crashes.

At one point I attempted to revive this patch and put the call into the JS wrapper code for the ArrayBuffer constructor (src/third_party/WebKit/Source/WebCore/bindings/v8/custom/V8ArrayBufferCustom.cpp), giving the hint that the ArrayBuffer destructor should also call AdjustAmountOfExternalAllocatedMemory. I don't remember where this got but clearly I never landed this patch. I think there are still issues with Web Workers, which can now access Typed Arrays, and also issues with Transferable support.

Happy to help look into this further. However, I have a feeling that either the AdjustAmountOfExternalAllocatedMemory API or implementation may need work. Also, it isn't 100% clear how well AdjustAmountOfExternalAllocatedMemory will work -- as I understand it, it will only artificially increase heap pressure, leading to more full GCs.

Labels: Type-Bug Priority-Medium
Status: Accepted
This update was done during clean-up of the issue tracker.

The crash still occurs with the attached file.
test.html
332 bytes View Download
Comment 6 by habl...@google.com, Apr 29 2015
Status: Available
Labels: Priority-2
Sign in to add a comment