Another evidence.
const a = Array( 1000 );
for( let i = 0; i < 14; i++ ){
a[ i ] = new Float32Array( 1000 );
}Out of memory. i < 12 works fine. 1000 * 4 * 12 = 48000 bytes, allocation of 56000 bytes throws.
Now, the problem is that floating point number itself is the separate 8-bytes object in the heap. Which leads to interesting effects. This code works fine.
const a = Array( 4096 );
for( let i = 0; i < 4096; i++ ){
a[ i ] = true;
}
console.log( a[ 0 ] );
This code still works fine, because integers are packed inside of the array.
const a = Array( 4096 );
for( let i = 0; i < 4096; i++ ){
a[ i ] = 1;
}
console.log( a[ 0 ] );
This code, however, gives you out of memory. Why? Because your array already took 16Kbytes, and when you put float inside it instantly adds 32Kbytes to the heap (each float is 64-bit object). It means that theoretically, you can get out of memory in a computationally intensive task.
const a = Array( 4096 );
for( let i = 0; i < 4096; i++ ){
a[ i ] = 1.5;
}
console.log( a[ 0 ] );
Solution? Never use arrays of floats. Use Float32Array instead.
So, fellas, how do you feel about SDK limits? They are closer than you might think, aren't they?
Think about that. 4K floating point numbers eats up the half of the available memory.
