Replying to:hakke
So, I have done some benchmarks for this library in the O3DS, and here are the results:
Creating 2D arrays:
64x64 - 81 ms
128x128 - 330 ms
256x256 - 1658 ms
Creating 1D arrays:
64 - 1 ms
128 - 3 ms
256 - 4 ms
Filling 2D arrays:
64x64 - 4197 ms
128x128 - 29790 ms
256x256 - 883 ms (what!)
Filling 1D arrays:
64 - 63 ms
128 - 229 ms
256 - 845 ms
Every operation was made with the provided functions and with LIM() returning 65536
You must have an O3DS, which makes for a good perspective because I didn't test it on the O3DS. Here's what I got on the N3DS:
Dimensioning 1D arrays:
Length 1-512 — 1-2 ms
Length 512-1024 — 2 ms
Length 1024-2048 — 8 Ms
Dimensioning 2D arrays:
Length 64, 64 — 21 ms
Length 128, 128 — 84 ms
Length 256, 256 — 387
Dimensioning 3D arrays:
Length 64, 64, 64 — 22 Ms
Length 128,128,128 — 84 ms
Length 256, 256, 256 — 389 ms
Dimensioning 4D arrays:
Length 64 ... 64 — 41 ms
Length 128 ... 128 — 161 ms
Length 256 ... 256 — 781 ms
Dimensioning 8D arrays (one, two, skip a few):
Length 64 ... 64 — 83 ms
Length 128 ... 128 — 331 ms
Length 256 ... 256 — 1551 ms
Dimensioning the array is one of the most effortless tasks in this library (just after checking the length), so these results should say a lot about the runtime consumption for the rest of the functions.
I mean, like I said, this probably isn't something you would want to call every frame inside a program. It's bent more towards storing complex data in complex (costly) ways. It's mass string manipulation for chrissake lol.
I'm glad to see you put the effort into timing these functions. Hadn't quite thought of it myself, I just knew it could be slow. I think that 883 ms one might be an error in the testing.
Edit: I would just like to note that the only reason why Dimensioning the 8D array is so quick is because all elements share the same value. The only thing the Dimensioning function has to do is set up the metadata for referencing any 256^8 elements. If you were to individualize each element, you would quickly run out of memory.