You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First and foremost, thank you for this outstanding tool! It has been incredibly helpful in identifying memory issues, and I truly appreciate the work that’s gone into it.
While debugging some memory leaks, I happened to find a discrepancy that I wanted to bring to your attention. When I ran:
bundle exec derailed bundle:mem
I noticed that a nested dependency was significantly increasing memory usage on boot, even with the default Rails configuration:
However, upon re-running bundle exec derailed bundle:mem, the memory consumption results remained unchanged. After investigating further, I found that derailed appears to load the full Rails stack regardless of the configuration in config/application.rb. The relevant code is here: https://github.com/zombocom/derailed_benchmarks/blob/main/bin/derailed#L90.
This behavior may not align with users’ expectations, especially when debugging memory issues, as it could lead to a mismatch between actual application memory usage and what derailed reports. I understand that the documentation does mention that certain components (e.g., ActiveRecord) can be skipped, but the current behavior could be misleading when attempting more granular memory optimization.
Would it be possible to consider an enhancement that allows derailed to respect the customized Rails boot process, or to clarify this behavior in the documentation?
Thank you again for all your efforts on this project! Happy to assist further if needed.
Best,
Ivan
The text was updated successfully, but these errors were encountered:
I was also looking at reducing my memory footprint by eliminating action_mailbox however I note that If you roll config/application.rb back to: require "rails/all"
and then run: RAILS_ENV=production rails server
and then run: bundle exec derailed exec perf:mem
then action_mailbox will not show in your memory footprint anymore without any need to selectively require rails gems.
I suspect rails is lazy loading it. It is a bit confusing that the static benchmarking identifies gems like this in the default output of derailed however the documentation does say "Booting your app will always be more accurate".
derailed bundle:mem has no way to know that you have included a gem in your bundle but not loaded it, unless it actually runs your app - I agree this is confusing and sometimes unintuitive, but this is well-documented in the readme (see screencap below). I would welcome a PR to further clarify things or call out some of the specific cases you ran into.
First and foremost, thank you for this outstanding tool! It has been incredibly helpful in identifying memory issues, and I truly appreciate the work that’s gone into it.
While debugging some memory leaks, I happened to find a discrepancy that I wanted to bring to your attention. When I ran:
bundle exec derailed bundle:mem
I noticed that a nested dependency was significantly increasing memory usage on boot, even with the default Rails configuration:
To address this, I adjusted config/application.rb to load only the required components:
However, upon re-running
bundle exec derailed bundle:mem
, the memory consumption results remained unchanged. After investigating further, I found that derailed appears to load the full Rails stack regardless of the configuration in config/application.rb. The relevant code is here: https://github.com/zombocom/derailed_benchmarks/blob/main/bin/derailed#L90.This behavior may not align with users’ expectations, especially when debugging memory issues, as it could lead to a mismatch between actual application memory usage and what derailed reports. I understand that the documentation does mention that certain components (e.g., ActiveRecord) can be skipped, but the current behavior could be misleading when attempting more granular memory optimization.
Would it be possible to consider an enhancement that allows derailed to respect the customized Rails boot process, or to clarify this behavior in the documentation?
Thank you again for all your efforts on this project! Happy to assist further if needed.
Best,
Ivan
The text was updated successfully, but these errors were encountered: