nice write-up! I wonder tho - did the optimization really affect CI wall time? In my experience such micro optimization rarely move the needle - it obviously matters because a lot jobs are running in parallel, but did it in the end improved dev experience? (honest question, just curious)
Optimizing Ruby Path Methods
61–66 of 66 posts
Re: Optimizing Ruby Path Methods
#62nice write-up! I wonder tho - did the optimization really affect CI wall time? In my experience such micro optimization rarely move the needle - it obviously matters because a lot jobs are running in parallel, but did it in the end improved dev experience? (honest question, just curious)
It was just one of many.
Alone it wouldn't have been very noticeable, but I did many small optimizations like that, which ultimately shaved about 20 seconds of setup time.
Looking from another angle, the app boot time on CI (not eager loading) was a bit more than 10 seconds, this saved over half a second, so a ~5% gain for an afternoon of work.
Re: Optimizing Ruby Path Methods
#63nice write-up! I wonder tho - did the optimization really affect CI wall time? In my experience such micro optimization rarely move the needle - it obviously matters because a lot jobs are running in parallel, but did it in the end improved dev experience? (honest question, just curious)
It was just one of many. Alone it wouldn't have been very noticeable, but I did many small optimizations like that, which ultimately shaved about 20 seconds of setup time. Looking from another angle, the app boot time on CI (not eager loading) was a bit more than 10 seconds, this saved over half a second, so a ~5% gain for an afternoon of work.
that sounds nice, thanks for sharing The Numbers! :D
Re: Optimizing Ruby Path Methods
#64Makes me miss Ruby. Been in node typescript recently. Everything is a callback returning a promise in some weird resolution chain, mapped and conditional types, having to define schemas for everything and getting yelled at by lsp all day... Oh then you gotta write react components and worry about rerenders and undefined behavior caused by impurity in state, npm, arcane .json configs Versus active record, mvc, yaml co…
Spot on. The worst thing is digging through 500 lines of nested JSON just to find one tiny type mismatch that broke the build. Most diff tools make it worse by showing 100 changes when 99 of them are just whitespace noise. Really makes you miss the simplicity of Ruby/Rails.
Re: Optimizing Ruby Path Methods
#65> Given that the Intercom monolith CI runs with 1350 parallel workers by default Wow! I'd love to hear more about how that's achieved
Nothing ground breaking we simply deploy Buildkite agents on EC2 nodes. As mentioned in the post, the only thing really limiting CI parallelism is the ratio of "setup time" vs "test time". If your setup time is too long, you hit diminishing returns fast.
Thank you for sharing – with 1350 workers I can appreciate the reduction of setup time!
Re: Optimizing Ruby Path Methods
#66Makes me miss Ruby. Been in node typescript recently. Everything is a callback returning a promise in some weird resolution chain, mapped and conditional types, having to define schemas for everything and getting yelled at by lsp all day... Oh then you gotta write react components and worry about rerenders and undefined behavior caused by impurity in state, npm, arcane .json configs Versus active record, mvc, yaml co…
> Everything is a callback returning a promise in some weird resolution chain Care to provide some examples of this? This hasn't been my experience, in general.
Processing async messages received over a socket with multiple namespaces.
Any async chain really where the steps are in a pipeline