Summary
Add a --profile flag to gengo test that reports peak VM resource usage alongside the existing pass/fail output. The goal is to give integrators concrete, workload-grounded numbers for sizing engine_init_with_config parameters (see #57).
Motivation
When embedding Gengo with fixed resource ceilings, integrators need to know what limits are actually required by their scripts. Without measured data, the practical outcome is that everyone sets limits to the maximum and the safety guarantees of per-instance configuration become meaningless.
Static analysis cannot give confident answers for a dynamic language. The right signal comes from running representative workloads and observing actual peak usage.
Approach
Run existing test blocks normally, but wrap each block's execution with VM state snapshots. After each block, record:
ops — total instruction countheap — peak heap bytes allocatedstack — peak stack depth (slots)objects — peak live object count
Report these alongside the pass/fail result:
test add_numbers OK ops=1842 heap=2.1KB stack=12 objects=4
test parse_record OK ops=8431 heap=14.3KB stack=28 objects=61
test validate_alert OK ops=3210 heap=6.8KB stack=19 objects=22
peak across all tests: ops=8431 heap=14.3KB stack=28 objects=61
The final summary line gives the integrator a single row to base their config on.
Design notes
test blocks serve double duty: correctness and resource characterisation. No new language keyword needed.- A single execution per block is sufficient. Resource usage is deterministic; the N-iteration calibration loop that wall-clock timing requires is not needed here.
- The flag should not affect pass/fail behaviour or exit codes.
- The output format should be machine-readable enough for CI to parse if needed (consider
--profile=json).
Out of scope
- Tracking resource usage across imports or multi-file modules (v1: per-block only).
- Wall-clock timing (already reported; orthogonal to this feature).
- A separate
bench block keyword.
Depends on
Summary
Add a
--profileflag togengo testthat reports peak VM resource usage alongside the existing pass/fail output. The goal is to give integrators concrete, workload-grounded numbers for sizingengine_init_with_configparameters (see #57).Motivation
When embedding Gengo with fixed resource ceilings, integrators need to know what limits are actually required by their scripts. Without measured data, the practical outcome is that everyone sets limits to the maximum and the safety guarantees of per-instance configuration become meaningless.
Static analysis cannot give confident answers for a dynamic language. The right signal comes from running representative workloads and observing actual peak usage.
Approach
Run existing
testblocks normally, but wrap each block's execution with VM state snapshots. After each block, record:ops— total instruction countheap— peak heap bytes allocatedstack— peak stack depth (slots)objects— peak live object countReport these alongside the pass/fail result:
The final summary line gives the integrator a single row to base their config on.
Design notes
testblocks serve double duty: correctness and resource characterisation. No new language keyword needed.--profile=json).Out of scope
benchblock keyword.Depends on