activeadmin: reloading much slower after 2.1 upgrade in development mode for a larger code base and about 25 active admin entities
Expected behavior
We were hoping the release 2 would bring some reload performance improvements in development mode.
Actual behavior
Reload performance (after touching some class in development mode) has become extremely slow. Strange enough enough, initial load is still about the same speed.
Context
- rails 5.2.x
- ruby 2.6.x
- tested on 2 mac’s : i5 / 16gb ram
analysis
from the logs it seems that active admin now somehow triggers a multitude of the same class reloads, below just an extract of one request log that appears to trigger class reloading of the same classes multiple times (and the amount of times seems to be increasing per request)
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: already initialized constant BOOTSWATCH_V3
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: previous definition of BOOTSWATCH_V3 was here
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: already initialized constant RANKDIR
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: previous definition of RANKDIR was here
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: already initialized constant BOOTSWATCH_V3
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: previous definition of BOOTSWATCH_V3 was here
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: already initialized constant RANKDIR
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: previous definition of RANKDIR was here
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: already initialized constant BOOTSWATCH_V3
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: previous definition of BOOTSWATCH_V3 was here
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: already initialized constant RANKDIR
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: previous definition of RANKDIR was here
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: already initialized constant BOOTSWATCH_V3
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: previous definition of BOOTSWATCH_V3 was here
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: already initialized constant RANKDIR
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: previous definition of RANKDIR was here
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: already initialized constant BOOTSWATCH_V3
/Users/koen/Personal/allcrux/app/admin/customer.rb:66: warning: previous definition of BOOTSWATCH_V3 was here
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: already initialized constant RANKDIR
/Users/koen/Personal/allcrux/app/admin/user.rb:7: warning: previous definition of RANKDIR was here
...
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 5
- Comments: 17 (7 by maintainers)
Managed to reproduce with:
Even if I undo the change and refresh (without reloading rails), it’s basically the same
HTH ?
Is this still an issue in 2.6? I’m running Rails 5.2 with ActiveAdmin 2.6 and this exact behavior is occurring. Boot up and refreshes are fast, one small change and the app grinds to a halt ☹️ I’ve tried back down to 2.0 with no luck as well.
Here is a flame graph right after boot with no code changes:
And here is a flame graph after adding an
sto alink_totag name and saving and reloading the page:just confirming for the recent readers and posters that after doing all updates and being on ruby 2.6.5 and rails 6.0.1 with active admin 2.3.1 and addons 1.7.1 we don’t have the issue anymore (as the original poster of the issue)
@deivid-rodriguez I just tried and I can reproduce this on Rails 6.
I tried to reproduce this, but I couldn’t. I thought our test application was unlikely to reproduce since it doesn’t use
listenand theEventedFileUpdateChecker, but still couldn’t reproduce after adding those.I recall something about
listenperforming better on Linux because the underlying notification library being more efficient, maybe it’s related to that?Anyways, I plan to revert this in #5801 for the time being.