On Mon, 4 Jul 2005, Daisuke Maki wrote:
> I have found DateTime unsuitable to quite a few tasks for
> various unfortunate reasons; which is a shame given the level of
> following and amount of design time that's gone into it.
And I quite agree. It's a shame if we don't fix this and make
DateTime.pm useful in any project -- and damnit I want to see it
survive in Perl6.
Well, I'd take Sam's message with a grain of salt. I use it in lots of
projects, and I know it's being used by lots of other people for lots of
things. The idea that it's "too slow" is bogus. It might be too
slow/bulky if you're creating thousands or hundreds of thousands of
objects at once, but even then I wonder if it is.
So without anymore adew, here's my braindump of things that needs
reviewing, and possible solutions:
DateTime.pm
- Prioritize features in DateTime.pm, and figure out the
most effective area to improve
- Use XS, where feasible. Move more existing PurePerl stuff
in *PP.pm modules
I think most everything that can be XS already is. XS has its own
overhead, and if you're just calling lots of Perl functions in XS,
particularly OO stuff, it may not be that much faster. I tried rewriting
duration addition in XS and it didn't help at all.
Locale / TimeZone
Given...
- Locale and TimeZones are singletons
- They are not *that* often used
Possible Improvements:
- Defer loading them until absolutely necessary
That's already done.
- Do not keep copy of a these objects in memory,
and keep the ID only
This would be _slow_. Going to disk every time you need to look up locale
or time zone information would be a huge speed hit.
- (collary: keep necessary flags like "is_floating"
in memory as part of DateTime's blessed hash)
This isn't checked all that often.
Also implement in XS?
Implementing time zones in XS as native C data structures would almost
certainly be a huge win. Unfortunately I don't have the C chops for this.
Locales are pretty small and I doubt they're a big speed hit.
Frankly, I thought Sam's message was a bit hand-wavy. He says:
I can see why you'd want to ship a copy of the locale information and
timezone database, but IMHO there needs to be a way that these can be
coded to be a little more space/file efficient.
But it's not clear if he's looked at the locales. They're already pretty
tiny, just a few small arrays or hashes for each one. It's not clear how
you could make them any smaller, and they're only loaded as needed!
Anyway, before people rush off down various paths I'd suggest some
profiling and benchmarking, rather than just "making it faster".
The first question to answer is what are people doing with these objects?
I suspect the biggest benefit would be simply to speed up object creation,
rather than the datetime math bits. Secondly, I think slimming down time
zones would be a big win (for memory savings), and speeding them up would
be nice although not necessarily that noticeable. After that improving
datetime math would be good, I think.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
