Hello, fellow Snappers. I have come to ask for help optimizing one of my recent projects (i promise its not the one which got yanked away from here recently)
So I was making a terminal system for a yet another Snap! OS, I made a write [] :: pen block that adds text passed into it with support for text wrap and multilines (i will get to scrolling-on-demand sooner or later after i finally know how to optimize the block)
Now, since the block definition is sort of big, I will give you this innocent looking script pic of my write [] :: pen block:
I think the main problem for optimizing is maybe because of the difference between unoptimized and optimized list processing blocks or just because that the block definition is massiver than the chance of me finishing all of my coding projects (sheesh)
Or maybe because I'm doing all my stuff wrong, average me.
how do you actually use this block within your project? when i try using it the text ends up pretty low on the screen and i need a seperate loop to render it
20% of the time is spent setting block attributes (that doesn't include any inputs, just the set attribute itself), 29% is spent in the join block, 33% in the split block. manipulating rings and setting definitions is just too slow, and i'm not really sure why you did it that way? it seems like a very overcomplicated way to do it, it would be far better to just store the screen text in a variable.
i'm guessing you didn't store the screen text in a variable because that wouldn't keep it nicely within the library, but if you consider that necessary you could probably just use a block variable.
i'll make a first draft with a regular global variable.
i know how to read a flame graph
i dont know what MultiArgMorph.prototype.addInput and Process.prototype.blockMatching and SyntaxElementMorph.prototype.fixLayout/</< and all of that is.
what I'm saying is that it would be great to have a tutorial that tells people how to improve their project speed
I see practically no changes, yet this version somehow does it faster than in a blink of an eye! (however word wrapping (typo, sry) is broken, which was the same broken as before, ill fix that myself)
EDIT: i read more, you just made the screen text a variable (hmph, maybe i was "overcomplicating")
most of the important stuff is around evaluateBlock, it's on the left right before it starts splitting up into a bunch of different things (each type of block)
"Morph" pretty much means any gui element. a lot of things in snap are glued to the ui elements which is why blocks (even when just being ran) are always "BlockMorph"
the lump on the right side is drawing the ui, notably including drawing the stage and all the sprites. it usually doesn't take long compared to blocks.
everything else is either pretty unimportant or stuff i don't know much about.
i did actually redo the rest of the block just now, the behavior isn't the same (the last line of multiple doesn't go to the next line automatically, text wrapping now works correctly) but i'm guessing you'd prefer that anyways. it still adds to the end of existing lines which i'm not sure was intended but that part's the same as how it was before. the other blocks should also be a smidge faster and none of them rely on any other custom blocks now
The OP block execution time [ms]
Most overhead comes from the strange concept of storing screen text by metaprogramming.
With MP removed (screen text may be stored somehow, say as a variable)
)) 