### Author Topic: HP Prime Relative Speed Testing- What is REALLY faster?  (Read 5411 times)

0 Members and 1 Guest are viewing this topic.

#### iconmaster

• LV3 Member (Next: 100)
• Posts: 82
• Rating: +5/-0
##### HP Prime Relative Speed Testing- What is REALLY faster?
« on: October 08, 2014, 05:30:45 pm »
As you guys may know, I'm working on an application that (in a way) optimizes HPPL code. So recently, I've been time-testing several methods of computation. So if you want to know absolutely what's faster to execute, you now have this thread!

I take 10,000 to 40,000 executions of a code snippet, and average the returned execution times. All parts of the programs being tested against each other have all other variables/code held constant. This isn't EXACTLY how long each operation takes; since there's boilerplate in there, too, all the times are relative. I did all of these on a physical calculator.

All units are in microseconds.

Now, on to the times!

PIECEWISE vs. IF...THEN...ELSE vs. IFTE

This was a test that looked like this:

Spoiler For Spoiler:
Code: [Select]
TEST1()BEGIN X:=RANDINT(1,3); RETURN PIECEWISE(X==1,3,X==2,2,1);END;TEST2()BEGIN X:=RANDINT(1,3); IF X==1 THEN  RETURN 3; ELSE  IF X==2 THEN   RETURN 2;  ELSE   RETURN 1;  END; END;END;TEST3()BEGIN X:=RANDINT(1,3); RETURN IFTE(X==1,3,IFTE(X==2,2,3));END;

So it tested an IF and a sub-IF.

The results are:

 PIECEWISE IF...THEN...ELSE IFTE 115.3 μs 117.4 μs 115.2 μs

Conclusion: IFTE is very slightly faster here, but PIECEWISE might actually be better for larger chains of ELSEs. IF...END is right out.

PIECEWISE vs. IF...THEN...ELSE vs. IFTE... REDUX!

Let's test this thing against a version with no sub-case.

Spoiler For Spoiler:
Code: [Select]
TEST1()BEGIN X:=RANDINT(1,2); RETURN PIECEWISE(X==1,3,4);END;TEST2()BEGIN X:=RANDINT(1,2); IF X==1 THEN  RETURN 3; ELSE  RETURN 4; END;END;TEST3()BEGIN X:=RANDINT(1,2); RETURN IFTE(X==1,3,4);END;

The results are:

 PIECEWISE IF...THEN...ELSE IFTE 100.6 μs 99.5 μs 98.5 μs

Conclusion: IFTE is the clear winner for simple IF cases.

MAKELIST vs. FOR

Let's execute a function. 1,000 times.

Spoiler For Spoiler:
Code: [Select]
FF(X)BEGIN RETURN X;END;TEST1()BEGIN MAKELIST(FF(I),I,1,1000);END;TEST2()BEGIN FOR I FROM 1 TO 1000 DO  FF(I); END;END;

The results of this test are:

 MAKELIST FOR 12,900 μs 15,200 μs

Conclusion: MAKELIST is faster. Use it instead of for loops even if you throw away what it returns.

MAKELIST vs. FOR, Part 2

Let's make them go backwards.

Spoiler For Spoiler:
Code: [Select]
FF(X)BEGIN RETURN X;END;TEST1()BEGIN MAKELIST(FF(I),I,1000,1,-1);END;TEST2()BEGIN FOR I FROM 1000 DOWNTO 1 DO  FF(I); END;END;

The results of this test are:

 MAKELIST FOR 14,200 μs 15,200 μs

Conclusion: MAKELIST takes a hit here, but is still better than FOR.

MAKELIST vs. FOR, Part 3

we had -1 as a step, so let's try 2.

Spoiler For Spoiler:
Code: [Select]
FF(X)BEGIN RETURN X;END;TEST1()BEGIN MAKELIST(FF(I),I,1,2000,2);END;TEST2()BEGIN FOR I FROM 1 TO 2000 STEP 2 DO  FF(I); END;END;

The results of this test are:

 MAKELIST FOR 13,700 μs 15,200 μs

Conclusion: MAKELIST still wins. Also, the fact that FOR kept getting the same time each run is really creepy.

To get an int: From a string, list, or matrix?

What is the best way to store ints? Let's find out:

Spoiler For Spoiler:
Code: [Select]
SS:="1234567890";TT:={48,49,50,51,52,53,54,55,56,57,58};MM:=[[48,49,50,51,52,53,54,55,56,57,58]];TEST1()BEGIN RETURN SS[3];END;TEST2()BEGIN RETURN TT[3];END;TEST3()BEGIN RETURN MM[1,3];END;

The results were:

 STRING LIST MATRIX 54.0 μs 47.1 μs 63.0 μs

Conclusion: Strings, quite surprisingly, suck. Not so surprisingly, matrices are bad at storing 1D data.

Real 2D data - Lists of Matrices?

Well, what is a matrix good at? 2D data, right? Well, let's see:

Spoiler For Spoiler:
Code: [Select]
TT:={{1,2,3},{4,5,6}};MM:=[[1,2,3],[4,5,6]];TEST1()BEGIN RETURN TT[1,2];END;TEST2()BEGIN RETURN MM[1,2];END;

The results were:

 LIST MATRIX 48.7 μs 53.3 μs

Conclusion: If you want speed, lists seem like the way to go.

3D data: Lists vs. complex arrays

Well, matrices can technically store 2 reals per slot: Complex arrays exist. So let's see if that's a good idea.

Spoiler For Spoiler:
Code: [Select]
TT:={{{1,1},{2,2}},{{3,3},{4,4}}};MM:=[[(1,1),(2,2)],[(3,3),(4,4)]];TEST1()BEGIN RETURN TT[1,2,1];END;TEST2()BEGIN RETURN IM(MM[1,2]);END;

The results were:

 LIST MATRIX 50.3 μs 60.0 μs

Conclusion: Matrices are useless.

Well, unless you're doing math with them, I GUESS.

GETPIX vs. Lists

Maybe getting ints from a grob is faster than ints from a list. Or maybe even reals from a list!

Test 1 is GETPIX. Test 2 is getting a value from a 2d list of #ints. Test 3 is getting from a list of reals.

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(MAKELIST(#0,Y,1,100),X,1,100);TTT=MAKELIST(MAKELIST(0,Y,1,100),X,1,100);EXPORT TST()BEGIN GETPIX_P(G1,10,10);END;EXPORT TST2()BEGIN TT[10,10];END;EXPORT TST3()BEGIN TTT[10,10];END;ONCOMPILE()BEGIN DIMGROB_P(G1,100,100);END;lol_hax=ONCOMPILE();

Here are the results:

 GETPIX INTS[x,y] REALS[x,y] 91.2 μs 82.8 μs 50.0 μs

Conclusion: GETPIX is slower than list access, at least for smallish indices. However, the main problem is probably the fact that you're getting back an integer, which is slow.

Big 1D Data

Let's compare strings to lists again. Let's bring this to THE MAX.

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(49,X,1,10000);TTT=ΣLIST(MAKELIST("1",X,1,10000));EXPORT TST()BEGIN TT[9999];END;EXPORT TST2()BEGIN TTT[9999];END;

The results are:

 LIST[9999] STRING[9999] 81.8 μs 88.4 μs

Conclusion: Lists still rule, but the divide IS closing ever so slightly.

2D data: Let's get big

The biggest power of 10 I can get for a list dimension is 100x100. Hmm.

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(MAKELIST(Y,Y,1,100),X,1,100);MM=MAKEMAT(I+J,100,100);EXPORT TST()BEGIN TT[99,99]END;EXPORT TST2()BEGIN MM[99,99]END;EXPORT TST3()BEGINEND;

The results were:

 LIST[99,99] MAT[99,99] 82.2 μs 97 μs

Conclusion: Lists are still better. I'd test them out for more beefy values, but I can't. I run out of memory first!

Setting lists and strings

Well, I was just informed that you can put values IN strings. So let's test that out!

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(49,X,1,1000);EXPORT TTT=ΣLIST(MAKELIST("1",X,1,1000));EXPORT TST()BEGIN TT[999]:=5326;END;EXPORT TST2()BEGIN TTT[999]:=5326;END;

The results were:

 LIST[999] STRING[999] 613.0 μs 112.6 μs

Conclusion: Setting values is much, much slower than getting them. Here, strings serve as an EXTREMELY good storage mechanism. So strings are better if you're willing to have a longer access time.

Making large strings

How does one make a large string programmatically? Well, there's the built in ΣLIST function that works, but what else can work? CHAR could do.

The strings are 100 characters long.

Spoiler For Spoiler:
Code: [Select]
EXPORT TST()BEGIN ΣLIST(MAKELIST("1",X,1,100));END;EXPORT TST2()BEGIN CHAR(MAKELIST(49,X,1,100));END;

The results are:

 ΣLIST CHAR 2,153 μs 561 μs

Conclusion: CHAR is by far better here. It's a good thing CHAR works on lists!

Even More Iteration Code

ITERATE is a function that exists. It's hard to make it work like MAKELIST, but sometimes you don't need it to work like MAKELIST .

Spoiler For Spoiler:
Code: [Select]
FF()BEGINEND;EXPORT TST()BEGIN MAKELIST(FF(),X,1,1000);END;EXPORT TST2()BEGIN ITERATE(FF(),X,1,1000);END;EXPORT TST3()BEGIN FOR I FROM 1 TO 1000 DO  FF(); END;END;

The results are as follows:

 MAKELIST ITERATE FOR 10,500 μs 7,900 μs 18,900 μs

Conclusion: If you don't care too much about the iteration count, ITERATE is better. I would bet it to be superior even if you put code in FF to make ITERATE give you back a real iteration value.

... Do I bet?

I'm feeling lucky.

Spoiler For Spoiler:
Code: [Select]
FF(X)BEGIN RETURN X+1;END;EXPORT TST()BEGIN MAKELIST(FF(X),X,1,1000);END;EXPORT TST2()BEGIN ITERATE(FF(X),X,1,1000);END;EXPORT TST3()BEGIN FOR I FROM 1 TO 1000 DO  FF(I); END;END;

The results are:

 MAKELIST ITERATE FOR 35,700 μs 39,300 μs 48,200 μs

Conclusion: Passing a parameter costs you a lot of time.

Oh, and I guess I lost that bet.

Fun fact with lists: Use LIST[0] to get the last element of a list. Set something to LIST[0] to append it to the end of the list. This is a sensible way to do things. Yessir.

Well, that's really all the useful ones I have right now. I'll do more later. Feel free to ask me for more comparisons!
« Last Edit: October 09, 2014, 08:37:13 pm by iconmaster »

#### DJ Omnimaga

• Now active at https://codewalr.us
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55821
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #1 on: October 08, 2014, 05:54:56 pm »
(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. )

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.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### iconmaster

• LV3 Member (Next: 100)
• Posts: 82
• Rating: +5/-0
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #2 on: October 08, 2014, 09:35:25 pm »
(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. )

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.

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.

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.

#### bb010g

• LV6 Super Member (Next: 500)
• Posts: 427
• Rating: +22/-1
• I do stuff
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #3 on: October 08, 2014, 10:05:18 pm »
I must say I'm surprised on MAKELIST & IFTE being fastest. Could you try a 3 conditional PIECEWISE vs. IFTE test? Also, you forgot 1D ([1,2,3]) vectors. (Although you can't nest those outside of CAS.)
Arch Linux user
Haskell newbie | Warming up to Lua | Being dragged into C++
Calculators: HP 35s, Casio Prizm, TI-Nspire CX CAS, HP-28s, HP Prime, Mathematica 9 (if that counts)
π: 3.14...; l: 108; i: 105; e: 101; l+i+e: 314
THE CAKE IS A LIE IS A PIE

#### DJ Omnimaga

• Now active at https://codewalr.us
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55821
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #4 on: October 08, 2014, 10:24:25 pm »
(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. )

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.

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.

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.
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.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### bb010g

• LV6 Super Member (Next: 500)
• Posts: 427
• Rating: +22/-1
• I do stuff
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #5 on: October 08, 2014, 10:26:01 pm »
(If this test was done with a ClassPad II, I would be 65 years old and retired by the time it's finished. )

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.

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.

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.
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.
Don't forget the memory allocation is more generous for GROBs.
Arch Linux user
Haskell newbie | Warming up to Lua | Being dragged into C++
Calculators: HP 35s, Casio Prizm, TI-Nspire CX CAS, HP-28s, HP Prime, Mathematica 9 (if that counts)
π: 3.14...; l: 108; i: 105; e: 101; l+i+e: 314
THE CAKE IS A LIE IS A PIE

#### DJ Omnimaga

• Now active at https://codewalr.us
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55821
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #6 on: October 08, 2014, 10:29:25 pm »
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?
« Last Edit: October 08, 2014, 10:36:00 pm by DJ Omnimaga »
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### bb010g

• LV6 Super Member (Next: 500)
• Posts: 427
• Rating: +22/-1
• I do stuff
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #7 on: October 08, 2014, 10:31:06 pm »
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.
Arch Linux user
Haskell newbie | Warming up to Lua | Being dragged into C++
Calculators: HP 35s, Casio Prizm, TI-Nspire CX CAS, HP-28s, HP Prime, Mathematica 9 (if that counts)
π: 3.14...; l: 108; i: 105; e: 101; l+i+e: 314
THE CAKE IS A LIE IS A PIE

#### DJ Omnimaga

• Now active at https://codewalr.us
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55821
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #8 on: October 08, 2014, 10:37:57 pm »
Ah ok. IIRC list limitations were removed or increased in the 2nd firmware. At first there were leftover limits from the HP 39gII and people complained. However, I wouldn't take large GROB capacity for granted. When I run multiple games that involves usage of GROB then attempt running a particularly complex program such as Cute Invaders or my pseudo 3D thing, large chunks of graphics fail to be displayed or are truncated (in the case of Cute Invaders, some frames are missing, resulting into extreme sprite flicker). I suspect it's a memory leak issue caused by firmware bugs. Basically, pre-rendering an entire 256x48 tilemap made of 16x16 tiles into a very large 4096x768 GROB then attempting to display a 320x240 chunk of it at once is not recommended (at least for the time being), not that it's very memory-efficient anyway.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### timwessman

• LV3 Member (Next: 100)
• Posts: 94
• Rating: +32/-0
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #9 on: October 09, 2014, 12:16:54 am »
I think your matrix/list results will change dramatically if you have much larger lists and matrices.

The reason why is that a matrix has a single type and constant sizing of each object. It can encode things in a much more efficient way since you do not have an identifier for each number. In a list, each number will be much larger since the type of the object much be encoded as well as the size to the next object.

In short, a matrix should be much faster once you have more then a very small number of objects to jump over since it is a direct index due to all objects being known. It will also be much smaller then an equally sized list.

A string should also overtake a list for much the same reason. The comment in the release notes about "string"[n] avoiding memory copy was because previously you had to call a function to get a specific character  ( MID("ABCDE",3,1) vs "ABCDE"[3] IIRC). Thus your string would get copied unnecessarily.

I am not surprise about the IFTE and MAKELIST being the fastest.
TW

Although I work for the HP calculator group, the comments and opinions I post here are my own.

#### iconmaster

• LV3 Member (Next: 100)
• Posts: 82
• Rating: +5/-0
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #10 on: October 09, 2014, 06:13:39 pm »
Okay, here's more speed tests! I'll put the more relevant ones in the OP.

GETPIX vs. Lists

Maybe getting ints from a grob is faster than ints from a list. Or maybe even reals from a list!

Test 1 is GETPIX. Test 2 is getting a value from a 2d list of #ints. Test 3 is getting from a list of reals.

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(MAKELIST(#0,Y,1,100),X,1,100);TTT=MAKELIST(MAKELIST(0,Y,1,100),X,1,100);EXPORT TST()BEGIN GETPIX_P(G1,10,10);END;EXPORT TST2()BEGIN TT[10,10];END;EXPORT TST3()BEGIN TTT[10,10];END;ONCOMPILE()BEGIN DIMGROB_P(G1,100,100);END;lol_hax=ONCOMPILE();

Here are the results:

 GETPIX INTS[x,y] REALS[x,y] 91.2 μs 82.8 μs 50.0 μs

Conclusion: GETPIX is slower than list access, at least for smallish indices. However, the main problem is probably the fact that you're getting back an integer, which is slow.

Big 1D Data

Let's compare strings to lists again. Let's bring this to THE MAX.

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(49,X,1,10000);TTT=ΣLIST(MAKELIST("1",X,1,10000));EXPORT TST()BEGIN TT[9999];END;EXPORT TST2()BEGIN TTT[9999];END;

The results are:

 LIST[9999] STRING[9999] 81.8 μs 88.4 μs

Conclusion: Lists still rule, but the divide IS closing ever so slightly.

2D data: Let's get big

The biggest power of 10 I can get for a list dimension is 100x100. Hmm.

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(MAKELIST(Y,Y,1,100),X,1,100);MM=MAKEMAT(I+J,100,100);EXPORT TST()BEGIN TT[99,99]END;EXPORT TST2()BEGIN MM[99,99]END;EXPORT TST3()BEGINEND;

The results were:

 LIST[99,99] MAT[99,99] 82.2 μs 97 μs

Conclusion: Lists are still better. I'd test them out for more beefy values, but I can't. I run out of memory first!

Setting lists and strings

Well, I was just informed that you can put values IN strings. So let's test that out!

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(49,X,1,1000);EXPORT TTT=ΣLIST(MAKELIST("1",X,1,1000));EXPORT TST()BEGIN TT[999]:=5326;END;EXPORT TST2()BEGIN TTT[999]:=5326;END;

The results were:

 LIST[999] STRING[999] 613.0 μs 112.6 μs

Conclusion: Setting values is much, much slower than getting them. Here, strings serve as an EXTREMELY good storage mechanism. So strings are better if you're willing to have a longer access time.

Making large strings

How does one make a large string programmatically? Well, there's the built in ΣLIST function that works, but what else can work? CHAR could do.

The strings are 100 characters long.

Spoiler For Spoiler:
Code: [Select]
EXPORT TST()BEGIN ΣLIST(MAKELIST("1",X,1,100));END;EXPORT TST2()BEGIN CHAR(MAKELIST(49,X,1,100));END;

The results are:

 ΣLIST CHAR 2,153 μs 561 μs

Conclusion: CHAR is by far better here. It's a good thing CHAR works on lists!

Even More Iteration Code

ITERATE is a function that exists. It's hard to make it work like MAKELIST, but sometimes you don't need it to work like MAKELIST .

Spoiler For Spoiler:
Code: [Select]
FF()BEGINEND;EXPORT TST()BEGIN MAKELIST(FF(),X,1,1000);END;EXPORT TST2()BEGIN ITERATE(FF(),X,1,1000);END;EXPORT TST3()BEGIN FOR I FROM 1 TO 1000 DO  FF(); END;END;

The results are as follows:

 MAKELIST ITERATE FOR 10,500 μs 7,900 μs 18,900 μs

Conclusion: If you don't care too much about the iteration count, ITERATE is better. I would bet it to be superior even if you put code in FF to make ITERATE give you back a real iteration value.

... Do I bet?

I'm feeling lucky.

Spoiler For Spoiler:
Code: [Select]
FF(X)BEGIN RETURN X+1;END;EXPORT TST()BEGIN MAKELIST(FF(X),X,1,1000);END;EXPORT TST2()BEGIN ITERATE(FF(X),X,1,1000);END;EXPORT TST3()BEGIN FOR I FROM 1 TO 1000 DO  FF(I); END;END;

The results are:

 MAKELIST ITERATE FOR 35,700 μs 39,300 μs 48,200 μs

Conclusion: Passing a parameter costs you a lot of time.

Oh, and I guess I lost that bet.
« Last Edit: October 09, 2014, 08:29:49 pm by iconmaster »

#### DJ Omnimaga

• Now active at https://codewalr.us
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55821
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #11 on: October 09, 2014, 11:52:38 pm »
Thanks for the new tests. Also, Getpix is not too bad it seems. The much easier map editing will be worth the speed loss I guess.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF

#### iconmaster

• LV3 Member (Next: 100)
• Posts: 82
• Rating: +5/-0
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #12 on: October 10, 2014, 09:42:29 pm »
Thinking about GETPIX again, I was wondering about SETTING data. So here is:

PIXON vs. List Set

Spoiler For Spoiler:
Code: [Select]
TT=MAKELIST(MAKELIST(#0,Y,1,100),X,1,100);TTT=MAKELIST(MAKELIST(0,Y,1,100),X,1,100);EXPORT TST()BEGIN PIXON_P(G1,50,50,#0);END;EXPORT TST2()BEGIN TT[50,50]:=#0;END;EXPORT TST3()BEGIN TTT[50,50]:=0;END;ONCOMPILE()BEGIN DIMGROB_P(G1,100,100);END;lol_hax=ONCOMPILE;

The results were:

 PIXON_P INTS REALS 74 μs 4,144 μs 3,616 μs

Conclusion: PIXON is impossibly fast. So fast, in fact, that I'm wondering if I messed up my time test somewhere. Of course, even if pixels are really fast, you have to worry about working with ints, which are noticeably slower than reals. If those results are real, though, I might have to suggest working with grobs myself.

#### DJ Omnimaga

• Now active at https://codewalr.us
• CoT Emeritus
• LV15 Omnimagician (Next: --)
• Posts: 55821
• Rating: +3151/-232
• CodeWalrus founder & retired Omnimaga founder
##### Re: HP Prime Relative Speed Testing- What is REALLY faster?
« Reply #13 on: October 10, 2014, 11:41:07 pm »
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.
In case you are wondering where I went, I left Omni back in 2015 to form CodeWalrus due to various reasons explained back then, but I stopped calc dev in 2016 and am now mostly active on the CW Discord server at https://discord.gg/cuZcfcF