On Aug 7, 2014, at 11:23 AM, Dave Rolsky <auta...@urth.org> wrote: >> I think the overhead comes in the DateTime::Locale::_register() function, >> which is called once for each locale returned by DateTime::Locale::Catalog. >> I would not think any locales would be loaded until they were needed. > > And you would be correct. The individual locale classes are not loaded until > you call DateTime::Locale->load
I see. So _register does not load them, but is still the startup bottleneck. What on earth is it doing? > What could speed things up would be to pre-generate the data structures that > are built by calling ->register on everything in the Catalog module. It builds up in-memory data structures for all of the locales? Wow. Yeah, seems like those could be encapsulated in the locales themselves or something, no? > That all said, DT::Locale is woefully crufty and out of date. I haven't kept > up to date with the CLDR data for years because the approach that DT::Locale > uses to generate individual locales makes it incredibly hard to deal with > data format changes in CLDR. Ah. So some locale results will probably be wrong now, eh? > Nick Patch had mentioned that he was interested in working on proper CLDR > support for Perl (which is more than just DateTime info), and I was hoping > he'd take all this over ;) Is CLDR::Number part of that, perhaps? http://search.cpan.org/dist/CLDR-Number/ I have updated Sqitch to defer loading DateTime at all until it is needed. Alas, it is often needed. Sure would be nice to cut down on this startup time in general. Best, David
signature.asc
Description: Message signed with OpenPGP using GPGMail
