Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve performance by 10% #1260
Inspired by a blog post  on the 'allocation_stats' gem I looked into
Describe your pull request and problem statement here.
lsegal left a comment •
Thanks for the optimization PR!
A few notes to help get this through:
The general feedback here (besides the specific points) is that this new addition seems to break expected boundaries of the NamespaceMapper module. It seems odd to me to add methods to an outer module that are only used by one including class.
It would be nice to have a more general purpose abstraction so that it's more obvious how all of these new methods fit together, otherwise it will be very easy to forego them in the future and regress on the performance benefits-- i.e. I could see another developer forgetting to use these cached matches and relying on
I renamed the methods, moved them to RegistryResolver as private methods (but documented them anyway) and hooked into
This of course creates additional coupling between the RegistryResolver and the NamespaceMapper through the 'super' calls (which at least will break on renames and changes in number of parameters, so chance of silently losing functionality seems slim), but I don't think there is any way to avoid that.
Performance gain is still ~10% (actually it seems more like 15-20%, but I do not sufficiently trust my measurement methodology to claim that much)
lsegal left a comment
Thanks for following up! A few more notes but with the following other comments addressed this looks good to go.
I'm not too concerned about this-- the Mapper->Resolver coupling already exists through the inclusion of the Mapper module by Resolver and its reliance on included Mapper methods. That is normal and expected coupling, and (ideally but I haven't fully confirmed this) tests start failing if any of those super methods change.