Performance and dates

I suggest - for optional modules (like dates), only import

    > them when they are required (when the plot actually has a
    > date) - for all modules try to minimise the amount of code
    > that will execute upon import, especially function calls.

    > What do you think?

Sounds great. Thanks for tracking this one down. A 10% speedup is
well worth it. It sounds like the dates module should also cache the
timezone info. Do you want to take the lead on this one?

JDH

Out of these timezones in dates.py
UTC = timezone('UTC')
Eastern = timezone('US/Eastern')
Central = timezone('US/Central')
Mountain = timezone('US/Mountain')
Pacific = timezone('US/Pacific')
London = timezone('Europe/London')
Paris = timezone('Europe/Paris')
Berlin = timezone('Europe/Berlin')
Moscow = timezone('Europe/Moscow')

As far as I can see the only timezones actually used are
UTC - as a function default value, and Pacific - used in __main__
Is it OK to remove all the unused ones, or is there something that
relies on them?

Steve

···

On Sun, 2004-12-12 at 15:09 -0600, John Hunter wrote:

    > I suggest - for optional modules (like dates), only import
    > them when they are required (when the plot actually has a
    > date) - for all modules try to minimise the amount of code
    > that will execute upon import, especially function calls.

    > What do you think?

Sounds great. Thanks for tracking this one down. A 10% speedup is
well worth it. It sounds like the dates module should also cache the
timezone info. Do you want to take the lead on this one?

JDH