Dave, I agree about taking it with a grain of salt.
However,
a) it is true that DateTime is slow (compared to other alternatives), and
b) It's just not good that we give people excuse like this to
not to use DateTime or to make it look like DateTime is not up to par
So I think we should be taking the performance issue seriously.
> Anyway, before people rush off down various paths I'd suggest some
> profiling and benchmarking, rather than just "making it faster".
I lost the data along the way, but if I remember correctly, the
slowest bits were:
-> DateTime::new
-> Params::Validate
-> timezones or locales (I forget)
-> date math
(It took way too long to generate the profiling data, so I really
don't feel like taking it again...)
> 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.
>From looking at the code, I think there are still much more that can
be done in XS. Let's take DateTime->new, for example. When called,
new() calls these functions from within:
_ymd2rd (XS)
_time_as_seconds (XS)
_normalize_nanoseconds
_calc_utc_rd
_handle_offset_modifier
_calc_local_rd
The last 4 functions can definitely be implemented in C -- they are
probably good candidates, too, because most of they are mostly
responsible for doing integer arithmatic that is much better handled
in C.
I also would like to suggest that it might make sense to put most of
the data in C structs, e.g.
struct dt {
long utc_rd_days;
long utc_rd_secs;
long local_rd_days;
long local_rd_secs;
...
};
# DateTime's blessed hash would look like
#
# { _xs_state => $c_struct, ... other fields }
Then we'd be manipulating the dt->utc_rd_days, dt->utc_rd_secs, etc
fields directly instead of SVs. This way we can do probably 90% of the
internal calculations in C, and we can also minimize the memory foot
print.
To summarize... I was already looking at writing Locales in C (looks
like that mail didn't get sent to the list...(*1)) and minimizing the
foot print for DT::Duration, but I suppose I can do TimeZones first?
(*1) http://www.nntp.perl.org/group/perl.datetime/5859
P.S. - attached is a patch for DT::Locale in XS (there are still test failures)
--d
xs-locale.patch
Description: Binary data
generate_xs_from_icu
Description: Binary data
