Repository navigation
Replace generated Dirty method usage with targets - #113
Conversation
I've been looking into memory usage of my application, and, even with previous optimizations, generated attribute methods are still one of the largest individual sources of memory. To address this, I've been thinking through some solutions where we may be able to define methods lazily or even not at all (and just use method_missing). Especially for infrequently used methods, this seems like it could be a reasonable tradeoff. This commit replaces usage of two of the less frequently used attribute methods with their underlying method call. Subjectively, I think the new code is better anyways since it avoids `send` and method name allocation, but it also ensures the methods don't get slower if we were to remove the Dirty method generation in the future.
|
Also happy to modernize/get CI working on newer versions of things if desired, it looks like #112 would fix tests for Rails 8.1 as advertised |
That's something I've been wondering for a while about Active Record itself. Surely, methods other than
Nah, this is just terrible for copy-on-write and post deploy latency. Either we define eagerly or we always go through |
Yeah, that's basically what I found. Allegedly ~1000 uses of all other attribute methods across every model (based on searching, so could be more). Clearly |
I've been looking into memory usage of my application, and, even with previous optimizations, generated attribute methods are still one of the largest individual sources of memory. To address this, I've been thinking through some solutions where we may be able to define methods lazily or even not at all (and just use method_missing). Especially for infrequently used methods, this seems like it could be a reasonable tradeoff.
This commit replaces usage of two of the less frequently used attribute methods with their underlying method call. Subjectively, I think the new code is better anyways since it avoids
sendand method name allocation, but it also ensures the methods don't get slower if we were to remove the Dirty method generation in the future.