Speed up gdk commands by 200ms
What does this merge request do and why?
This speeds up all gdk commands by around 200ms (on my M3 MacBook Pro)
by moving the support/pg_bindir
Ruby script into the current GDK
process.
Starting a ruby
script can take up to 60ms. And we currently run
support/pg_bindir
twice, once when we validate_yaml!
and once when
we populate GDK.config
. We could also look into memoizing this value
but it only takes around 20ms to compute using mise (asdf might be 11
longer?).
While this is a great DX improvement (up to 50% speedup of
gdk config get
executions!), the speedup is also relevant for
programmatically accessing config options in Multiple Cells with one GDK (#1945 - closed).
How to set up and validate locally
- Checkout
main
- Run
time gdk config get rails_web.enabled
- Note down the time it took
- Checkout this branch
- Run
time gdk config get rails_web.enabled
- Compare the time (expectation: about 420ms -> 220ms)
Benchmark
main
$ hyperfine --warmup 10 "gdk config get gdk.debug"
Benchmark 1: gdk config get gdk.debug
Time (mean ± σ): 937.7 ms ± 157.5 ms [User: 823.9 ms, System: 182.7 ms]
Range (min … max): 782.3 ms … 1298.7 ms 10 runs
This branch
$ hyperfine --warmup 10 "gdk config get gdk.debug"
Benchmark 1: gdk config get gdk.debug
Time (mean ± σ): 516.8 ms ± 13.7 ms [User: 488.6 ms, System: 95.3 ms]
Range (min … max): 495.5 ms … 535.0 ms 10 runs
Impacted categories
The following categories relate to this merge request:
-
gdk-reliability - e.g. When a GDK action fails to complete. -
gdk-usability - e.g. Improvements or suggestions around how the GDK functions. -
gdk-performance - e.g. When a GDK action is slow or times out.
Merge request checklist
-
This change is backward compatible. If not, please include steps to communicate to our users. -
Tests added for new functionality. If not, please raise an issue to follow-up. -
Documentation added/updated, if needed. -
Announcement added, if change is notable. -
gdk doctor
test added, if needed. -
Add the ~highlight
label if this MR should be included in theCHANGELOG.md
.
Edited by Peter Leitzen