How Can I Optimize ActiveAdmin Performance with 400+ Admin Files in Rails 5.1.4?

Below is some background on why you might see delays when using a large number of admin files and some ideas to help mitigate the issue.

---

Why the Delay Happens

ActiveAdmin, by design, loads each admin resource file (from your app/admin folder) during initialization. With about 400 files, this means:

• Resource Registration: Every file calls ActiveAdmin.register or similar commands, and each registration builds up a menu, routes, and configuration.
• Early Loading: This registration happens before controller actions even begin. Rails isn’t waiting to render a view—the delay is in processing all those resource definitions.

Rails’ autoloading improvements (such as lazy loading via autoload) are aimed at reducing the memory footprint and accelerating boot times by loading only what’s needed. However, with ActiveAdmin, the registration process itself is triggered by loading each admin file. When you remove half, the amount of processing (and associated side effects) drops, which is why performance improves noticeably.

---

Steps to Improve Performance

1. Evaluate Admin File Contents:
   Check if any of your admin files perform extra work at load time (e.g., complex Ruby code, extra includes, or heavy computations). Deferring such code can help. For example, consider wrapping noncritical code inside an ActiveSupport.on_load callback so it’s only executed when the corresponding framework (or part of ActiveAdmin) is needed.

   RUBYCopied
   ActiveSupport.on_load(:active_admin) do
     # Place code here that only needs to run when ActiveAdmin loads
   end

2. Optimize Resource Registrations:

   • Consolidate files if possible: If several admin resources share configuration or can be consolidated, reducing sheer file count might help.
   • Review DSL Hooks: Some DSL calls might trigger additional processing. Check if you have before_filters or other config blocks that add delays.

3. Cache Initialization:
   Although development mode is meant to reflect changes quickly, consider using caching strategies or preloading frameworks when there are many files. For example, Rails allows you to control whether core libraries are preloaded on startup using options like preload_frameworks (though by default this is set to false so Rails uses lazy loading).

4. Update or Patch ActiveAdmin:
   There have been improvements over time in how ActiveAdmin handles large numbers of resource definitions. Checking if newer versions address these performance concerns or offer alternative registration patterns might be worthwhile. Sometimes, community plugins or patches help reduce the overhead.

---

Final Thoughts

The key issue is that all the resource files are loaded and processed before any controller action starts, which is an approach that works fine for smaller sets but becomes a problem with hundreds of files. By deferring noncritical code, consolidating configuration, and potentially leveraging lazy loading where possible, you can help reduce the initialization delay.

If you continue to encounter delays even after these steps, consider using profiling tools or benchmarking the initialization steps (for example, inserting logging timestamps in your configuration) to pinpoint which parts of the registration process are the slowest.

Let me know if you have further questions regarding Rails or need more detailed insights on a particular aspect.