You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no out-of-the-box way to profile Wasm executions via Wasmi.
One way this could look like is to collect information during Wasm executions such as total number of Wasmi instructions executed, total number of branches taken, total time spent in host functions, total instruction dispatch time, and for each instruction number of its execution and total execution time.
We could collect all this information in a singular struct during execution.
In order to not compromise performance we must put this functionality behind a crate feature profiling. This functionality must not degrade performance when not enabled. Ideally it would not even significantly degrade performance when enabled but this is probably a pipedream.
The Wasmi CLI should expose this functionality to its users.
This data enables Wasmi users and developers alike to better understand performance issues in their Wasm blobs or the Wasmi engine itself and to optimize for specific use cases.
Since the Wasmi bytecode enum is extremely large it might be a good idea to write a proc. macro to generate the associated profiling struct type from it to simplify keeping everything in sync.
After a Wasmi execution the profiler then outputs its collected data to the user. This could be formatted as JSON or something similar.
Currently there is no out-of-the-box way to profile Wasm executions via Wasmi.
One way this could look like is to collect information during Wasm executions such as total number of Wasmi instructions executed, total number of branches taken, total time spent in host functions, total instruction dispatch time, and for each instruction number of its execution and total execution time.
We could collect all this information in a singular
struct
during execution.In order to not compromise performance we must put this functionality behind a crate feature
profiling
. This functionality must not degrade performance when not enabled. Ideally it would not even significantly degrade performance when enabled but this is probably a pipedream.The Wasmi CLI should expose this functionality to its users.
This data enables Wasmi users and developers alike to better understand performance issues in their Wasm blobs or the Wasmi engine itself and to optimize for specific use cases.
Since the Wasmi bytecode
enum
is extremely large it might be a good idea to write a proc. macro to generate the associated profilingstruct
type from it to simplify keeping everything in sync.After a Wasmi execution the profiler then outputs its collected data to the user. This could be formatted as JSON or something similar.
The text was updated successfully, but these errors were encountered: