Closed ChrisPenner closed 2 months ago
Am I reading it right that these timings are largely the same and maybe even a bit slower?
@ceedubs Yup pretty much, it's not much of a noticeable improvement.
The ones that are slower by a couple microseconds may be within variance, things like counting to a million are like 16ms faster which is at least noticeable.
Whether it's actually worth merging this is up for debate
FWIW, we have been running this in staging all day. I feel like my data on the improvement is all kinda within the margin or error but it's certainly not slower. We've been running all the nimbus integration tests against this and its all been good.
@stew Given that this kinda makes the code uglier Dan and I figure if it's not a noticeable improvement we'll probably just skip this one.
Code's a bit ugly, still needs refactoring
Choose your PR title well: Your pull request title is what's used to create release notes, so please make it descriptive of the change itself, which may be different from the initial motivation to make the change.
Overview
What does this change accomplish and why? i.e. How does it change the user experience? i.e. What was the old behavior/API and what is the new behavior/API?
Feel free to include "before and after" examples if appropriate. (You can copy/paste screenshots directly into this editor.)
If relevant, which Github issues does it close? (See closing-issues-using-keywords.)
Implementation notes
How does it accomplish it, in broad strokes? i.e. How does it change the Haskell codebase?
Interesting/controversial decisions
Include anything that you thought twice about, debated, chose arbitrarily, etc. What could have been done differently, but wasn't? And why?
Test coverage
Loose ends
Link to related issues that address things you didn't get to. Stuff you encountered on the way and decided not to include in this PR.