It seems that this proposal is trying to use debug_print to extract profiling information. This is reasonable, but the use-case “get debug_print output from a canister” is a very valuable one, independent from profiling. I would even say it is more valuable than profiling!
So I suggest, also to build building blocks, to provide the feature “developer can get debug_print” output on its own (but in a way that the profiling use-case can use it of course).
Here is a strawman propsoal: We add a canister setting “debug_log_size”. This allow the controller to configure how much debug_print output should be preserved. Maybe with a default of 1MB?
The system maintains a buffer (no need to call it memory, there is no random writes) of that size per canister. debug_print appends to that buffer. If it gets larger than the configured size, the oldest debug_print entries disappear (i.e. a ringbuffer). The contents of the buffer is available to the controllers of the canister via the state tree. The buffer is preserved across traps and also across query-methods-executed-as-updates.
Maybe the system injects system-generated log messages when a message processing starts, and when it ends, so that the log becomes more helpful.
This would be already a huge improvement for our developers! And then the canister-level profiling use case can build on top of that easily, without additional system support.