Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
Rick Measham wrote: 2. Create DateTime::TimeZone::Olson::XS - The Olson Database is already an open-source, free distributable C library, would we not save considerable space/memory by creating an XS interface to the library? You would still have to create the timezone singletons -- unless you're suggesting that these would be destroyed when not in use, you would still end up running into the same memory issues once enough timezone objects have been created. Matt
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
You would still have to create the timezone singletons -- unless you're suggesting that these would be destroyed when not in use, you would still end up running into the same memory issues once enough timezone objects have been created. And you wouldn't be able to take advantage of page sharing. -J --
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
You would still have to create the timezone singletons -- unless you're suggesting that these would be destroyed when not in use, you would still end up running into the same memory issues once enough timezone objects have been created. And you wouldn't be able to take advantage of page sharing. But what if the the singleton object for each timezone was just a flyweight wrapper with the timezone name and some link to some database file with the information that could be quickly accessed through XS? Actually, I have no idea if this is possible, because I don't exactly know how each timezone object works. From the docs I see each object provides the following methods: offset_for_datetime( $dt ) offset_for_local_datetime( $dt ) name short_name_for_datetime( $dt ) is_floating is_utc is_olson category Is this ALL each timezone provides, and nothing else? Does anything directly access timezone object structures in any other way? Because if not, it should be pretty easy to create an XS wrapper to implement only these functions, even say by accessing the POSIX zoneinfo database given a timezone name? Or am I missing something? Rob
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
Is this ALL each timezone provides, and nothing else? Does anything directly access timezone object structures in any other way? Because if not, it should be pretty easy to create an XS wrapper to implement only these functions, even say by accessing the POSIX zoneinfo database given a timezone name? How many win32 (and non-POSIX systems) have the zoneinfo database? -J --
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
Is this ALL each timezone provides, and nothing else? Does anything directly access timezone object structures in any other way? Because if not, it should be pretty easy to create an XS wrapper to implement only these functions, even say by accessing the POSIX zoneinfo database given a timezone name? How many win32 (and non-POSIX systems) have the zoneinfo database? Yes, I know many non-POSIX systems don't have the zoneinfo database, but I was only using access to a zoneinfo database as an example, not as a definitive way of actually doing it. My point really is that if each timezone object only has to obey the method interface (which is about 10 methods and only 2 of those really require any calculations) and nothing inspects the objects internally or requires anything else from them, then it should be pretty easy to create some XS version which just accesses some indexed data structure, rather than having to pre-load a large amount of perl data structures into memory. That's all. I should probably just try and look this up myself, but I thought someone on the list would be better able to tell exactly how timezone objects are used, and whether only their methods are ever called, or whether other DateTime modules access the internal perl data structures themselves. Rob
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
My point really is that if each timezone object only has to obey the method interface (which is about 10 methods and only 2 of those really require any calculations) and nothing inspects the objects internally or requires anything else from them, then it should be pretty easy to create some XS version which just accesses some indexed data structure, rather than having to pre-load a large amount of perl data structures into memory. That's all. As I've said, I'd like to have the current code generator generate XS code instead of Perl. The generated code would contain C data structures instead of Perl, and would so presumably be smaller and quicker. Sticking the data into something like a Berkeley DB could be done as well, although it's probably better to do this at install time, rather than trying to ship these with the module. I should probably just try and look this up myself, but I thought someone on the list would be better able to tell exactly how timezone objects are used, and whether only their methods are ever called, or whether other DateTime modules access the internal perl data structures themselves. Only their methods. I like encapsulation. That's great to hear. It means it should be quite straight forward to actually do at some stage as/when you can find the correct algorithm and data structures in C to make it work quickly and efficiently. Just have to find someone with the time, energy and desire to do so. I probably should have asked my questions more this way from the very beginning. Rob
