> > 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
