PIECEWISE | IF...THEN...ELSE | IFTE |
115.3 μs | 117.4 μs | 115.2 μs |
PIECEWISE | IF...THEN...ELSE | IFTE |
100.6 μs | 99.5 μs | 98.5 μs |
MAKELIST | FOR |
12,900 μs | 15,200 μs |
MAKELIST | FOR |
14,200 μs | 15,200 μs |
MAKELIST | FOR |
13,700 μs | 15,200 μs |
STRING | LIST | MATRIX |
54.0 μs | 47.1 μs | 63.0 μs |
LIST | MATRIX |
48.7 μs | 53.3 μs |
LIST | MATRIX |
50.3 μs | 60.0 μs |
GETPIX | INTS[x,y] | REALS[x,y] |
91.2 μs | 82.8 μs | 50.0 μs |
LIST[9999] | STRING[9999] |
81.8 μs | 88.4 μs |
LIST[99,99] | MAT[99,99] |
82.2 μs | 97 μs |
LIST[999] | STRING[999] |
613.0 μs | 112.6 μs |
ΣLIST | CHAR |
2,153 μs | 561 μs |
MAKELIST | ITERATE | FOR |
10,500 μs | 7,900 μs | 18,900 μs |
MAKELIST | ITERATE | FOR |
35,700 μs | 39,300 μs | 48,200 μs |
(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. :trollface:)
Thanks a lot for this post by the way. THis might be pretty handy because sometimes we might need the fastest possible speed, but not be aware of what is actually faster. It sucks to have to rewrite most of the code after discovering we could have done it faster in certain ways >.<
Also, speed was a major concern for me regarding tilemapping because I was not sure if I should use lists, matrices, strings or images. I am not surprised that strings are slower, though, because on the TI models they were much slower than lists (in fact, the farther a character was in a string, the slower it was to read it, so inside a 2000 bytes large string, reading map data at the beginning was about 3 times faster than at the end). For data storage and reading, could you test how fast/slow it is with Pixel-test commands? Using such data would make it much easier to design tilemap data, but if the speed loss is considerable, then it might not be worth it.
Yeah that's what I mean. Some TI-84+ programmers use pictures to store map data, but on the HP Prime it's even more convenient in the way that pixel-test can actually detect which color the pixel is, while on the color 84+ it only detects if the pixel is transparent or not.(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. :trollface:)
Thanks a lot for this post by the way. THis might be pretty handy because sometimes we might need the fastest possible speed, but not be aware of what is actually faster. It sucks to have to rewrite most of the code after discovering we could have done it faster in certain ways >.<
Yeah, I know what you mean. Looking back at HP Tetris, I realize that representing the grid with a complex matrix was a bad idea. :PAlso, speed was a major concern for me regarding tilemapping because I was not sure if I should use lists, matrices, strings or images. I am not surprised that strings are slower, though, because on the TI models they were much slower than lists (in fact, the farther a character was in a string, the slower it was to read it, so inside a 2000 bytes large string, reading map data at the beginning was about 3 times faster than at the end). For data storage and reading, could you test how fast/slow it is with Pixel-test commands? Using such data would make it much easier to design tilemap data, but if the speed loss is considerable, then it might not be worth it.
Do you mean testing list access vs. pixel access? If that's what you mean, sure! Im going to guess that lists are faster, but who knows! This is why I'm testing.
Don't forget the memory allocation is more generous for GROBs.Yeah that's what I mean. Some TI-84+ programmers use pictures to store map data, but on the HP Prime it's even more convenient in the way that pixel-test can actually detect which color the pixel is, while on the color 84+ it only detects if the pixel is transparent or not.(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. :trollface:)
Thanks a lot for this post by the way. THis might be pretty handy because sometimes we might need the fastest possible speed, but not be aware of what is actually faster. It sucks to have to rewrite most of the code after discovering we could have done it faster in certain ways >.<
Yeah, I know what you mean. Looking back at HP Tetris, I realize that representing the grid with a complex matrix was a bad idea. :PAlso, speed was a major concern for me regarding tilemapping because I was not sure if I should use lists, matrices, strings or images. I am not surprised that strings are slower, though, because on the TI models they were much slower than lists (in fact, the farther a character was in a string, the slower it was to read it, so inside a 2000 bytes large string, reading map data at the beginning was about 3 times faster than at the end). For data storage and reading, could you test how fast/slow it is with Pixel-test commands? Using such data would make it much easier to design tilemap data, but if the speed loss is considerable, then it might not be worth it.
Do you mean testing list access vs. pixel access? If that's what you mean, sure! Im going to guess that lists are faster, but who knows! This is why I'm testing.
What do you mean? Are lists and matrices limited to a max amount of elements (eg on the 84+ it was 999 and on the 82 it was 99) or do you refer to how much larger GROB data is?I'm not sure about list size limitations, but IIRC Tim said that they treated GROBs more favourably memory-wise.
GETPIX | INTS[x,y] | REALS[x,y] |
91.2 μs | 82.8 μs | 50.0 μs |
LIST[9999] | STRING[9999] |
81.8 μs | 88.4 μs |
LIST[99,99] | MAT[99,99] |
82.2 μs | 97 μs |
LIST[999] | STRING[999] |
613.0 μs | 112.6 μs |
ΣLIST | CHAR |
2,153 μs | 561 μs |
MAKELIST | ITERATE | FOR |
10,500 μs | 7,900 μs | 18,900 μs |
MAKELIST | ITERATE | FOR |
35,700 μs | 39,300 μs | 48,200 μs |
PIXON_P | INTS | REALS |
74 μs | 4,144 μs | 3,616 μs |
On the other hand, if you try to store a picture-based map data with DIMGROB, then the result is atrociously large, since each pixel is like 64 bytes or so in unicode form (maybe more?). Size-wise, every other alternative is more viable, but again this calc has a lot of memory so that is not a big issue.