Speed of fetching from lists...

tsulej

I'm making a project ( http://scratch.mit.edu.ezproxyberklee.flo.org/projects/17114670/ ) which does vast number of math calculations (sin/cos/sqrt/tan…) so it is quite slow. I was thinking how to speed up a little bit and had idea to use “ancient” strategy to put precalculated trig functions to lists. It was suprise to me, that using list with precalculated data is 2-3 times slower than using corresponding trig function. Why??

Here is simple test project to ilustrate this issue:
http://scratch.mit.edu.ezproxyberklee.flo.org/projects/17460657/

CodeLegend

Huh… That is strange! I also noticed that reducing the repetitions (down to 500 each) does the opposite, and tab time is about 10 times better than function time! My guess is that when the same function is repeatedly called, its answer is temporarily saved, so doing it more makes it faster. Did you try implementing the list-pull function into the fractal project? If it uses decimal trig calculations, list-pull might be faster.

procd

That is slightly odd. I compiled your project and ran it and the compiled version was marginally quicker using tables than functions. I can only think that the table version is doing some wastefull updates perhaps for list monitors even though the list is not shown.
Does show that modern maths libraries are pretty quick though!

CodeLegend

procd wrote:
That is slightly odd. I compiled your project and ran it and the compiled version was marginally quicker using tables than functions. I can only think that the table version is doing some wastefull updates perhaps for list monitors even though the list is not shown.
Does show that modern maths libraries are pretty quick though!

What do you mean by ‘compile’?

procd

CodeLegend wrote:
procd wrote:
That is slightly odd. I compiled your project and ran it and the compiled version was marginally quicker using tables than functions. I can only think that the table version is doing some wastefull updates perhaps for list monitors even though the list is not shown.
Does show that modern maths libraries are pretty quick though!
What do you mean by ‘compile’?

This

nXIII

List operations in Scratch are in general really slow, because they have to find the list, calculate the index, check the index bounds, and finally access the list item. The function block, by comparison, just has to cast, switch on the operation, and call a primitive function.

drmcw

nXIII wrote:
List operations in Scratch are in general really slow, because they have to find the list, calculate the index, check the index bounds, and finally access the list item. The function block, by comparison, just has to cast, switch on the operation, and call a primitive function.

The compiled version is doing pretty much the same, looking up the list, check bounds and get the item, which isn't overly taxing. Similarly the function is a call to a Maths library to calculate Sin. I would expect a Sin calculation to be slower than some memory de-referencing and the compiled version is indeed faster for list access than function, although not by a huge margin. Scratch coming in 3 times slower for list access over function is a little surprising.

Last edited by drmcw (Feb. 17, 2014 17:56:53)

nXIII

drmcw wrote:
nXIII wrote:
List operations in Scratch are in general really slow, because they have to find the list, calculate the index, check the index bounds, and finally access the list item. The function block, by comparison, just has to cast, switch on the operation, and call a primitive function.
The compiled version is doing pretty much the same, looking up the list, check bounds and get the item, which isn't overly taxing. Similarly the function is a call to a Maths library to calculate Sin. I would expect a Sin calculation to be slower than some memory de-referencing and the compiled version is indeed faster for list access than function, although not by a huge margin. Scratch coming in 3 times slower for list access over function is a little surprising.

You do realize I was looking at the source code when I wrote that, right? ActionScript lists are not memory dereferences, and the string operations to get the list are slow (and probably not the same in the compiled version).

drmcw

No. But it's still surprising! Almost certainly not the same

tsulej

Thank you for deep explanation. So I stay with math functions in my project. And even do opposite, replace lists to just variables in calculations blocks.

QuillzToxic

nXIII wrote:
List operations in Scratch are in general really slow, because they have to find the list, calculate the index, check the index bounds, and finally access the list item. The function block, by comparison, just has to cast, switch on the operation, and call a primitive function.

Thats why Q-Login is sooooooooooooooo slow

(And it oftern gives up on very low-end systems XD)

Discuss Scratch