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
DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
Two thoughts on the TimeZone issue: 1. Create DateTime::TimeZone::Lite. - This would return a subset of the Olson data that assumed the current rules extend infinitely in both directions. - This would not be a prereq, or be installed by DateTime itself. - I suggest we might make this assumption on the grounds that we already make a similar assumption with DateTime: The Gregorian Calendar wasn't used back at the year 0, but DateTime assumes it does. 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? - The DateTime::TimeZone::Olson::XS module would be a part of the DateTime::TimeZone distro, and would be the default, if it can find the Olson database. Otherwise TimeZone falls back on the perlified version. Unfortunately I'm not a C programmer and, although I just read right through perlxs and perlxstut I'm still none-the-wiser ;) Cheers! Rick
Re: DateTime::TimeZone::Lite and DateTime::TimeZone::Olson::XS
On Sat, 15 Nov 2003, Rick Measham wrote: 1. Create DateTime::TimeZone::Lite. - This would return a subset of the Olson data that assumed the current rules extend infinitely in both directions. - This would not be a prereq, or be installed by DateTime itself. - I suggest we might make this assumption on the grounds that we already make a similar assumption with DateTime: The Gregorian Calendar wasn't used back at the year 0, but DateTime assumes it does. I'm really not sure how useful this is. Imagine you start using this now, then next year some time zone changes it's rules, so you install the latest version. Now all the year-old data is using the new rules, meaning that you end up with bogus conversions. If this were a calendaring app, that'd mean that old entries might suddenly become an hour off for nor apparent reason. 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? No it's not, actually. It's an open-source freely distributable set of a data and a few C programs. The interpretation is up to each system's core library. On Unix boxes, that means libc. Also, this would be limited to using epoch values, which means 32 bit ints. Avoiding this has always ben one of the main goals of the DateTime project! I think an XS implementation of the current API/code would be a much more useful thing. As I said, I'd like to implement it but I'm a bit short on tuits. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
