New addon: Timing and RTC profiler

[Joeclinton1]

Why this would be helpful

I would like a way for people to time their projects more easily. When optimizing a project timing is neccessary for implementation comparisons. I envision this timing method to allow for timing within absolute and relative terms.

Here's what I mean by relative timing:
The time for each block to run may be different per computer but it's time relative to any other block remains constant. As using the subtraction operator as an atomic unit (a logical choice due to it's prevelance in most projects), we can determine the cost of any block relative to the subtraction operator which we call the Relative Time Cost (RTC). The table that lists this RTC is given here: https://scratch.mit.edu/projects/725580642/

How this addon works

I envision this working in one of two ways:

Option 1: A START TIMING and END TIMING timing block. would be part of the debugger blocks category. The block starts and ends timing a particular section of the code, and has an input for a label. This is the most flexible option, but the blocks themselves might cause some overhead and it requires two new blocks to be added. The list of labelled timing sections is visually displayed.

Might look something like this:

Option 2: You can right click on a hat block (block stack) and hook a timer to it. This list of hooks is visually displayed. Once hooked, right click lets you unhook. A hat block displays that it is hooked with an icon in the top left. This times the time it takes to go from the hat block to exiting the thread attached to the hat block.

Then the debugger tab would have a new section called TIMING.
This would display for each of the labelled timing blocks / timed custom blocks:

• the absolute and relative (RTC) time averaged per call
• The number of times each was called
• An option to delete the hook (if using hooks).

Advantages of option 1:

• Flexible: Can time part of a thread, a whole thread, multiple threads.
• Intuitive to use: Putting a start and end block is quite clear.

Advantages of option 2:

• Easier to implement: Threads are the base level being run in the actual vm code. So it's not hard to check if the current thread is hooked, and time it.
• Doesn't require two new blocks: Option 1 needs two blocks to be created.
• No overhead. The hook is implemented in js. Option 1 has the timing called by what is essentially a custom block which will add overhead. Also means accounting for this overhead time.

Possible alternatives

No response

Additional context

I discussed this 4 years ago: #117
Since then the addon has grown, and the Debugger tools were added. I am confident this can be made without too much trouble now.

[Joeclinton1]

After some discussions with potential end users, I am going to go with the start and end timing blocks. However, I also think it would be cool, to be able to press a button and just start timing every thread in the project. then maybe a heat map of all the threads could be made, aswell as a list of them. Honestly i'm just going to do whatever I think is best, as I think I'm exactly the target audience for this addon, and so I know pretty well what we're going to want for it.

My main concern in addition to design choices is efficiency. As timing the blocks shouldn't slow the project down too much, also it needs to be able to be turned on and off with a switch, instead of always being on.

[Joeclinton1]

I'm going to begin development on this today. It's a relatively big addon, so rather than do it all at once, I'm going to develop it at the same time as using it for production. This is nice as any features I add will be added, because I needed them and hopefully encourage a useful interface and functionality. Additionally, it should make testing easier.

The development could takes months as i'm in no rush to finish this.