Reloading slow in development

[ryanb]

I did some quick benchmarking and found that adding Wallaby to our app adds over 1 second to code reloading time in development.

After changing the code and reloading the page it takes 2.6 second to finish loading a given page with Wallaby and 1.4 seconds if Wallaby is removed from the project. This is when reloading a page unrelated to the admin pages.

My guess is because Wallaby is force-reloading all models where as I believe Rails loads what it needs as needed.

What is the reason for Wallaby doing its own code reloading and not relying on Rails code reloading? Is it to support configuring decorators at the class level? If so perhaps you can store that config in a plain hash and attempt to apply it when using a decorator instance.

It seems like half the issues I've ran into have to do with the custom code reloading. This is a tricky thing to get right and will likely cause further issues in future Rails versions and conflicts with other gems.

Would it be possible to remove the custom code reloading and fall back to however Rails wants to load/reload the code?

[tian-im]

Hi @ryanb, the way how Wallaby works is it goes through all the eager_load_paths (which is all the folders under /app folder) and use require_dependency (which is the Rails way to require/load a file) to require all files, then Wallaby can build up a map of how things are associated, for example, which decorator to use for User model, especially when the associated decorator is under a namespace Admin::UserDecorator. Therefore, Wallaby relies on discovering all the classes under /app.

Maybe I can provide an option to disable the reload or disable the reloading by default. But if Wallaby reloading is disabled, issues will be introduced, for example, a newly added model not showing or a deleted model still showing. Then restart will be required.

I once thought maybe I can use a naming convention and add configurations to models so that it can resolve how models are associated with controllers/decorators/authorizers/servicers/paginators. However, this approach is also complex and has its own limitations.

[ryanb]

The performance issues which effect every page is a bummer, and I don’t know how you would optimize this except for reducing the amount of eager loading.

Is there any way you can have the code reloading only trigger when visiting a page within the engine? I don’t see why it needs to eager load everything if we aren’t using any part of Wallaby in the request.

[tian-im]

I think the calculation is done only once on every reload and all information will be then stored in the Wallaby::Map. Therefore, there shouldn't be any classes loading after the first page load.

But Wallaby does require quite a few assets from different gems, not sure if compiling the assets contribute to the slowness (which I guess it does). Maybe to reduce the assets should be the direction?

[ryanb]

I think the calculation is done only once on every reload and all information will be then stored in the Wallaby::Map. Therefore, there shouldn't be any classes loading after the first page load.

When there is a change made to the code Wallaby reloads everything, correct? This is the only case where there's a difference in the page loading with/without Wallaby.

But Wallaby does require quite a few assets from different gems, not sure if compiling the assets contribute to the slowness (which I guess it does). Maybe to reduce the assets should be the direction?

I think Sprockets caches this and only recompiles these assets when other assets change. I wasn't changing assets so I don't think this is the issue.

[tian-im]

Hmmm, let me see how I can optimize this process. Maybe just reload the files that Wallaby interests? or just the files that are changed? Let me do some experiments.

[ryanb]

@tian-im is it possible for Wallaby to only do its reloading for wallaby related requests? That would be ideal if we can't avoid the custom reloading.

[tian-im]

Yeah, that's also a good idea. Let me do some experiments.