Advice on how to implement block-by-block profiling

[Joeclinton1]

Hello,

I want to make a script which lets you time each block as it runs and then afterwards log how long every block in the project took to run. Finally I want to colour each block in the project depending on how long it took to run. Sort of like a heatmap.

After a lot of testing and careful reading I've figured out how the sequencer, thread, runtime and profiler work, but I can't figure out a way of doing what I want to do.

The profiler makes it possible to time frames, and will allow you to know the opcode and time duration of the frames, however it doesn't report the specific data id of blocks, making it impossible to figure out which time pairs with which blocks. That is an issue.
I tried getting the current block in the onframe callback, but there is a delay between calling onframe and the callback running, so by the time the callback runs the thread has already completed.

A second option is to create a set-interval function without a delay, which gets the currently running block and tries to time it. However, set interval is not very accurate for timing blocks, and can lag the browser. Grabbing the profiler.records also doesn't work.

A third option could be stopping the built in interval function from running and then running each block one by one, but i'm not sure if this is possible.

Any ideas are welcome.

[apple502j]

But... if you don't care about comparing results this may be possible. May need some VM hacks though, and not sure if addons can do it.

[Joeclinton1]

But that's the point, my aim is to time each block, to see how long it takes to execute. I'm just struggling to do that. Preferably I want to do it without changing the virtual machine code.

If I was to change the code I could make it so profiler.onFrame also returns the block data id and I'd be done.

I think disabling the main stepping function, and running each block one by one, with a timer added might work, though I think it would end up being far more complicated than I want it to be.

[apple502j]

I can 99% say you need to change VM code.

[Joeclinton1]

An addon can actually edit the code so it is possible. See my pull request for doing just that here: griffpatch/Scratch3-Dev-Tools#24

But it adds extra permissions and minor issues, which is undesirable.

Perhaps, it might be easiest if I make an api which can be requested. That way it won't need extra permissions, and won't need to insert any code.

[WorldLanguages]

Right now I'm playing a bit on using a Proxy to get events when something changes inside the Scratch VM object, and its children. It's a little hacky, but it could turn out to be very useful. Right now, the editor-stepping addon basically runs code with setInterval all the time, when there's probably a better way, if what we're waiting for produces some side effect in the VM object.

[WorldLanguages]

Update: using proxies probably won't work unless we use a library that helps us manage nested objects.

@apple502j made a fancy getter/setter trap for this usecase. It traps Thread objects.

const oldPush = Array.prototype.push;
Array.prototype.push = function(...args) {
        if (args[0] && args[0].hasOwnProperty('blockContainer') && args[0].hasOwnProperty('requestScriptGlowInFrame')) {
const thread = args[0];
        thread.__proto__._blockGlowInFrame = null;
        thread.__defineGetter__("blockGlowInFrame", function(){return this._blockGlowInFrame});
        thread.__defineSetter__("blockGlowInFrame", function(v){
            if (this._blockGlowInFrame) this.target.runtime.glowBlock(this._blockGlowInFrame, false);
            this._blockGlowInFrame = v;
            if (this._blockGlowInFrame) this.target.runtime.glowBlock(this._blockGlowInFrame, true);
            });
        }
return oldPush.apply(this, args)
  }

Keep in mind, if you want this to be an addon for the Scratch Addons extension, we should probably add this to some API (it's a bad idea to have addons mess with prototypes). However, I believe you do not plan to have this as an addon, at least yet, so it's fine. Anyway, if someday you want to port it, it won't be very hard.

[WorldLanguages]

Closing for inactivity