How and when to use a JS Array over BuiltIn Array

Archived Forums Questions & Answers
1

I attached the project file [19085-unity3d42_test.zip|19085] 200KB (Unity 4.3.1f1).

Description of a project:
We simulate a life cicle of a plant (or a life form). Life starts, grows, matures, reproduces (x times), dies. This goes forever or until there is no plant left on the grid.

19086-plant_life_1.jpg
19086-plant_life_1.jpg955×771 301 KB

See two main scripts:
Game.js
LifeForm.js

My questions in regards to arrays:

If I increase the array size beyond 32*32 (in fact 1024 items) the “Main thread” time ratio to “Renderer time” increases out of proportions.

Did I use the arrays in a correct way as they were intended to be used in Unity?

Game.js: function LifeFormDeliver()
How costly is JS array conversion to BuiltIn arrays?

Would it be faster (for a big array) to manualy copy the array instead of assigning it directly to a variable?

var area_free: Vector3;

var area_free_array = new Array();

area_free = area_free_array.ToBuiltin(Vector3) as Vector3;

Thank you in advance.

2
  • Use a built in array when you know the size in advance or don’t need to resize it very often.
  • Use a built in array if you know for a fact that Array/List/Whatever is slowing you down.
  • ArrayList had some bad reputation, likely because of overhead casting objects when accessing it.
  • Use List.< T > in favour of ArrayList as it accomplishes the same thing but is type safe and doesn’t cast.

Apologies for not giving your complete project a lot of attention; the script is large and the variable names are crypic like “b”, “bt” and “bc” which just makes it hard to figure out what your code is actually trying to achieve, so I gave up.

Built in arrays (Vector3) is faster than using arrays. However, they are not a lot faster and the general reason your scripts become slower with increasing sizes are generally:

  1. The algorithm has a poor time complexity.
  2. The data structure thrashes cache.

If your algorithm has poor time complexity, you may want to look into figuring out a different way of managing your simulation. For example, if you were doing something like:

for (..)
    for (..)

Then you probably are looking at an algorithm that has a time complexity of O(N^2). This means that if you increase the number of items from 5 to 10, it’s not 2 times as slow. It’s 25 (55) ops vs 100 (1010) ops, and it’s 4 times as slow.

Another issue can be cache thrashing and is a bit more complicated since you need to understand how the CPU cache lines and cache policy works. But generally you can think of your memory as one big line of data (bear with me). A cache line is like a segment of your data line. If you can avoid leaving the cache line, the CPU will work faster since it doesn’t have to pull new data from RAM. I won’t get into details, but you can start looking at a Z-Order curve or a “Morton Curve” on wiki. This particular memory mapping is good when you access neighbors in a 2D grid (perhaps you are doing the same?) and is applicable when you want to “for a given point, check the neighboring points for something” because the morton curve will remap your indices to lie in a cache line and not outside cache lines, for the most cases. I used this myself when I was doing a voxel engine and the results was about 3x lookup speed for my particular set of operations I did with each voxel (as opposed to just using a simple array with 3 ranks (float[,,]).

I also discussed speed difference of List and a built in array earlier, which you can read here.

3

You would never, ever use a JS Array. Similarly, ArrayList is obsolete and should be avoided. Use a generic List instead if the array is going to change size; it does everything JS Array and ArrayList do except faster/better.