Why is it that compiling a costume from a list can be so slow? Is there a way to make this process quicker? Is there some kind of process that makes this slow in the first place?
Could you post a link to a sample project that shows the issue?
If you make a list of pixels with components that are definitely always a numerical value like this:
it shouldn't take too long to compile that into a costume. Numerical operators always return a number.
Compared to something like this, where the given input could be a string:
It will take much longer, probably because it has to convert all the data into numbers.
You can make a number block that takes a number input and just reports it, so the output will be a number.
[scratchblocks]
(num (5) :: operators)
[/scratchblocks]
And do this:
It actually takes less time to make a costume of that data
What an example of great 'detective' work this is; and beautifully presented, too.
P.S.
I like how the block pictures pop out in the dark mode (dark theme).
Oh, wow. That's an impressive penalty for typing numbers into a list reporter. I'm fixing this right now, it should be exactly the same short duration for any of these representations. The good news, is, this can be done. Will be in the next minor release coming up before Christmas.
Thanks for this great analysis!
We've talked about this problem 2 months ago.
The performance degradation was obvious for the specific scenario, where the same costume data was slightly modified and reused.
But there are no "low hanging fruits" for a generic case.
The performance penalty is caused by the implicit conversion of a string to a number by JS engine. So if you take into account both manipulating pixel list and setting costume there will be no substantial difference. Actually, the list of char version is 2 x faster because calling a custom reporter causes extra delay.
Filling the entire costume with color is faster this way, with a precalculated pixel list. But it still 500 ms for 500x600 costume (or ~100ms for 240x360).
So maybe some APL construct based on reshaping can help with this.
Or building an array exponentially by
I wondered where has @pumpkinhead found the block I am seeing for the first time in my life. Now I know. It's from this project by @dardoro.
P.S.
I have a question. Do you mean this 
as a workaround completely avoiding the MAP being used at all?
P.P.S.
Another curious, hopefully not too silly, question: what does "APL construct based on reshaping" mean, can you give an example?
Luckily it turns out there is a low hanging fruit that solves all of these issues by explicitly converting data to numbers at the primitive level. This simple change - already tested - makes all variants equally fast. To be released later today.
No, rather to limit iterations.
This way list with 2^20 elements is created in 20 steps instead of 2^20 with a map primitive.
It's just a sidenote. I've read much about the expressive power of APL for array processing. So maybe effective filling an array with a const value is possible.
I'm curious, did You decide to store numeric literals as numbers in SyntaxElementMorph's?
Turns out I didn't need to. Simply explicitly making sure to convert whatever is stored inside a pixels-list to number using +value when sticking it into imageData has an astounding effect.
For other people:
(that's why we haven't needed to do a (new)Number(value)
Thank you for satisfying my unexpressed curiosity.
I didn't get the block from that project. I just saw uses of it in certain script pics, but I couldn't find the definition. I just make a new definition of it everytime I want to use it.
You're welcome 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.