Implement TZInfo.eager_load!

[casperisfine]

We recently instrumented our application to locate the source of the constant cache bumps we were seeing, and tzinfo came up as one of the sources.

In production environment, it's detrimental for performance to use lazy loading. It's much better to load everything upfront as part of boot.

[eregon]

Which constant(s) are defined when loading a new timezone?
#real_timezone itself looks fine.

[casperisfine]

If you use the "ruby datasource" it load the individual ruby definition file from tzinfo-data, e.g.: https://github.com/tzinfo/tzinfo-data/blob/324dcf757b014a5ac5f9a44d95b350fa3873a609/lib/tzinfo/data/definitions/Cuba.rb

And they all include TimezoneDefinition which bust the cache a couple more times via append_features:

    module TimezoneDefinition #:nodoc:
      # Adds class methods to the includee.
      #
      # @param base [Module] the includee.
      def self.append_features(base)
        super
        base.extend(Format2::TimezoneDefinition::ClassMethods)
        base.extend(ClassMethods)
      end

[philr]

Thanks for submitting this.

I've implemented something that will achieve the same thing in a slightly different way.

Commit 94be919 adds a preload! method to DataSource. This can be called with TZInfo::DataSource.get.preload!.

The implementation avoids the temporary creation of TimezoneProxy objects for each time zone and also preloads country data for hypothetical data source implementations where this is not loaded up front.

[casperisfine]

Thanks @philr, it however is infortunate it's not at least aliased as eager_load! as it's the Rails convention that allows to just do:

config.eager_load_namespaces << TZinfo

[philr]

I wasn't aware of that Rails convention.

I've made a further change (c4f177c) to add a TZInfo.eager_load! method in order to support that. The implementation calls the DataSource.

[casperisfine]

Thank you! That's very helpful.

[Skywildlogistics]

Good