Cache various lookups with Dry::Core::Cache

[timriley]

This PR uses Dry::Core::Cache to cache a few lookups that could otherwise be costly:

• Templates within paths
• Part classes within namespaces
• Scope classes within namespaces

@GustavoCaso I hope you don't mind me going ahead with this, I wanted to play around with what we could cache. And I figured we should use our existing caching helper from dry-core.

Before this change, we were ~5.5x slower than ActionController.

Warming up --------------------------------------
   action_controller     1.000  i/100ms
            dry-view     1.000  i/100ms
Calculating -------------------------------------
   action_controller      6.519  (± 0.0%) i/s -     33.000
            dry-view      1.171  (± 0.0%) i/s -      6.000

Comparison:
   action_controller:        6.5 i/s
            dry-view:        1.2 i/s - 5.56x slower

After this change, we're ~1.8x slower:

Warming up --------------------------------------
   action_controller     1.000  i/100ms
            dry-view     1.000  i/100ms
Calculating -------------------------------------
   action_controller      5.995  (±16.7%) i/s -     30.000
            dry-view      3.317  (± 0.0%) i/s -     17.000

Comparison:
   action_controller:        6.0 i/s
            dry-view:        3.3 i/s - 1.81x slower

Here's the latest profile diagram (run using Hotch and a new script I checked into the repo): bundle exec ruby benchmarks/profile_controller.rb

So no more low hanging fruit, as far as I can tell? Would definitely appreciate any thoughts on taking things from here. 👋 @GustavoCaso @solnic

[GustavoCaso]

@solnic I decided not to use dry/core/cache because according to the docs:

Allows you to cache call results that are solely determined by arguments.

In my opinion the template? method cannot be solely cache by there arguments:

def template?(name, format)

name and format could be the same for multiple directories so that is why I need to create a unique key using dir as well. But seing @timriley changes looks like we can pass multiple arguments to dry/core/cache fetch_or_store(root, dir, name, format) do

I guess would be nice to update the docs as well 😄

[GustavoCaso]

This is great!! 🎉 🎉

[solnic]

@timriley LGTM, it's already a great start. We should be able to make it at least equally fast eventually. I'll take another look at perf improvements once I get a chance.

[timriley]

@solnic cool, will do. FWIW I just moved some of the caching a little earlier, with
e178d41, and we're now just ~1.3-1.4x slower.

It's worth recognising that we're certainly doing a lot more in the dry-view side of this benchmark versus action view, at least in how we're preparing the scope for the template, e.g. checking for exposure dependencies, wrapping up values in parts, finding classes, etc., so this isn't truly an apples-for-apples comparison. Perhaps a better one would be e.g. using Draper to decorate every ivar in the Rails controller before it's passed to the template.

[solnic]

One more thing, MRI 2.6.0 has various optimizations that we benefit from, so here are the results running MRI 2.6.0.rc2:

∞ [ruby-2.6.0-rc2][node-v8.12.0] dry-view git(caching-with-dry-core) be ruby benchmarks/benchmark_controller.rb
Warming up --------------------------------------
   action_controller     1.000  i/100ms
            dry-view     1.000  i/100ms
Calculating -------------------------------------
   action_controller      7.135  (± 0.0%) i/s -     36.000  in   5.054691s
            dry-view      6.115  (± 0.0%) i/s -     31.000  in   5.077587s

Comparison:
   action_controller:        7.1 i/s
            dry-view:        6.1 i/s - 1.17x  slower

As you can see, the difference is meaningless, this probably means dry-view can easily become faster on future MRIs.

[solnic]

It's worth recognising that we're certainly doing a lot more in the dry-view side of this benchmark versus action view, at least in how we're preparing the scope for the template, e.g. checking for exposure dependencies, wrapping up values in parts, finding classes, etc., so this isn't truly an apples-for-apples comparison. Perhaps a better one would be e.g. using Draper to decorate every ivar in the Rails controller before it's passed to the template.

That is correct. OTOH it is a legit scenario, and a very common one, so it's probably worth having such a basic benchmark. To balance this better adding a more advanced scenario would be great too!