Only clear ActionView caches in dev when files change

[jhawthorn]

Builds on #35623 and #35628

This changes the dev-mode actionview cache expiration, which used to run before each request, to only change if any files in the view directories have changed.

This should make dev mode template rendering the same speed as production! ⚡️ (though I'm sure there will be other dev mode things slowing it down)

Todo

• Find out what people use that isn't a FileSystemResolver Make a changelog entry that those with non-FileSystemResolver resolvers will need to clear caches themselves if they want dev mode reloading.
• We will no longer get dev-mode reloading when using render file: (we can't exactly listen to all changes on/). Decide if that's okay.
• Measure how much it improves dev mode

[kaspth]

I'm really excited about this! Thanks for working on it.

[kaspth]

Did you look into swapping app.executor to app.reloader?

[kaspth]

Lovely! Code wise this is good to go for me.

As for the TODOs:

1. I'm guessing the strike means you've talked it over with @tenderlove or @eileencodes?

2. I didn't even know we had render file:, should we continue to support it? GitHub search only brought Action Pack tests on forks: https://github.com/search?l=Ruby&q=render+file%3A&type=Code

   Coupled with the fact that this says "old default" here:

   rails/actionview/lib/action_view/helpers/rendering_helper.rb

   Line 14 in e04af4e

   # * <tt>:file</tt> - Renders an explicit template file (this used to be the old default), add :locals to pass in those.

   I see what you mean about the caching too. Perhaps there's a way to just not bother with any caching in development for file: renders?

   rails/actionview/lib/action_view/template/resolver.rb

   Line 128 in e04af4e

   cached(key, [name, prefix, partial], details, locals) do

3. Looking forward to seeing the measure!

[jhawthorn]

I didn't even know we had render file:

PR incoming related to this 😉

EDIT: See #35688

[jhawthorn]

This is ready for review!

Benchmarks in my (very view heavy, not doing much else) test app look very promising!

Before

Warming up --------------------------------------
               GET /     5.000  i/100ms
Calculating -------------------------------------
               GET /     71.057  (±15.5%) i/s -    340.000  in   5.066397s

After

Warming up --------------------------------------
               GET /     8.000  i/100ms
Calculating -------------------------------------
               GET /     97.241  (±30.9%) i/s -    400.000  in   5.306943s

[kaspth]

@jhawthorn since #35688 has been merged, do we still need to talk about no dev mode reloading for render file: or can that be checked off?

[jhawthorn]

since #35688 has been merged, do we still need to talk about no dev mode reloading for render file: or can that be checked off?

Yep! We've lost reloading on the deprecated behaviour, which I think is fine.

I've added a CHANGELOG entry noting custom ActionView::Resolver subclasses (which should be pretty rare) may need to add their own cache clearing.

I think this is good to go!

[kaspth]

@jhawthorn ❤️

[kaspth]

I was wondering if we should expose ActionView::LookupContext::DetailsKey.clear as clear_cache on resolvers. iirc DetailsKey is private so users shouldn't know about that constant directly — and I don't know how else they'd clear the cache. What do you think?

[jhawthorn]

👍 I agree it needs a better (and not private) name. It's a little tricky because afaict having Resolver#clear_cache wouldn't currently work, when testing I got errors unless we cleared all the caches.

Maybe we should expose ActionView::CacheExpiry.clear_cache (ie. make it class-level and document it)

[kaspth]

Should the resolvers know about ActionView::CacheExpiry? Currently the cache expiry knows about the resolvers, so it seems off that we allow double "binding". Since it's just abstracting a reference to DetailsKey anyway, how about a class-level ActionView::Resolver.clear_caches?

Which we then also use in lieu of clear_cache in CacheExpiry.