Possible Startup Performance Regression introduced with PR#271
daumayr opened this issue · 4 comments
#271 prepares for actor snapshots by introducing serialisation, the new features are hidden behind VM flags and should not affect performance when unused.
Benchmarks for #271 reliably showed 8-9% increased average startup time for SOMns-graal with the List benchmark. Startup times for this benchmark have a high variation even on dev (317ms - 440ms), which is worse after #271 (325ms - 560ms).
The exact cause for this increase in startup performance is currently unknown and might be related to the introduction of new fields. The new fields can alter the memory layout and therefore allocations, GC behavior, etc.
Still looks like some serious regressions on startup across the board.
Hm, on my machine things looked better. By increasing the number of invocations we would get a more reliable picture, currently it's the average of three starts.
If additionals fields are the cause for performance regressions, we might want to consider using bytecode transformations to insert the fields only when we need them (i.e. tracing).
I would like to avoid the extra complexity of bytecode transformation. It would mean we need to start maintaining extra tooling, something that smells like a language extension. Not sure that would be worth the effort.
Also, we still haven't confirmed what the actual cause is.