Significantly long GnoVM test runtime

[zivkovicmilos]

Description

Running the gnovm test suite takes an extraordinarily long amount of time to execute:

time make --no-print-directory -C gnovm test  1005.06s user 23.11s system 160% cpu 10:42.20 total

For CI runs, take a look at an example GnoVM CI run:
https://github.com/gnolang/gno/actions/runs/7031801537/job/19134177743

Notice that pkg0, pkg1, pkg2take ~13mins to execute in the CI.

An additional problem is that we cannot execute the VM tests in parallel (t.Parallel()), since there are primitives in the VM preventing parallel execution (global vars).

This long test suite execution time takes a large toll on local development and CI workflows.

@ajnavarro @gfanton please add more info to this task if I've missed something, @petar-dambovaliev will look into the issue

[ajnavarro]

Maybe we should make the VM thread-safe, to make it possible to run several of them simultaneously.

[zivkovicmilos]

to make it possible to run several of them simultaneously.

This is actually something that is required down the line, we can't do gas estimations (through an RPC call, cc @MichaelFrazzy) and state transitions at the same time with the current VM

[petar-dambovaliev]

Maybe we should make the VM thread-safe, to make it possible to run several of them simultaneously.

I also lean towards this idea.
I made a profile on the slowest tests and the distribution of runtime is kind of equal across the board.
In other words, there is no single function bottleneck.
The only one that takes more than 2% of the runtime is

// NOTE: for allocation, use *Allocator.NewBlock.
func NewBlock(source BlockNode, parent *Block) *Block

It takes about 7% of the runtime.
It is worth improving it. It wouldn't fix the tests runtime, we still need to make them thread safe but it will help a bit with that and also make the general runtime faster.

[MichaelFrazzy]

to make it possible to run several of them simultaneously.

This is actually something that is required down the line, we can't do gas estimations (through an RPC call, cc @MichaelFrazzy) and state transitions at the same time with the current VM

Is this test similar in function to the benchmarking framework that Dylan set up or something that we've had for a while?