Add Config subclass with immutable Equalizer

[HashNotAdam]

When extending Dry::Configurable, the default is to initialize a Dry::Equalizer without immutability on the hash method.

When Dry::View fetches or stores a template, Dry::Core::Cache uses a hash of the arguments. Since this hashing will occur for every nested template, it can be quite computationally demanding. In the case of fetching or storing templates, the values being hashed shouldn't change and so the result can be memoized.

In my benchmarks, I'm using a highly contrived template that loads 100 nested templates that do nothing more than print out their name as well a couple of random numbers to ensure values aren't being cached so, while it is designed somewhat to replicate a site with many components, it's far from true to life. Saying this, my tests have found this has given me a roughly 75% performance increase:

Calculating -------------------------------------
              Before    100.263  (± 6.0%) i/s -      1.008k in  10.076792s
               After    174.497  (± 3.4%) i/s -      1.751k in  10.047389s

It's tricky to solve this elegantly so I'm very open to discussing alternative approaches.

One thing I considered was if there is support for adjusting these values at runtime. I couldn't think of any legitimate reason to do that but, if such a reason exists, I'm sure we could find a solution

[timriley]

Thank you so much for this (and #157), Adam!

Am definitely conscious that dry-view (and soon to be, hanami-view) is in need of some performance tuning, and your work here is a great start!

This is also good timing in that I've been doing work in dry-configurable lately. This has mostly been with a view to improving memory usage as much as possible, but it's a good moment to revisit overall performance and make sure I haven't swung the pendulum too far. (It's also doubly good timing in that dry-configurable will probably hit 1.0 in the next ~6 weeks, so we still have a window open for larger changes if required).

To this end, I'd be interested in exploring whether we can do work inside dry-configurable itself to make some of these changes in dry-view unnecessary. I'd like dry-configurable to be a library someone can pick up without having to worry about performance, even if it is used in more performance-sensitive situations like you point out for dry-view.

So: would you mind sharing the benchmark you used for assessing your changes to dry-view? I'd love to be able to give it a run while looking for dry-configuring and compare the results.

[HashNotAdam]

No worries, @timriley, I've pushed up this repo