Re: DateTime.pm on a Diet
On Thu, Jul 21, 2005 at 01:54:30PM +1000, Rick Measham wrote: I want to wrap this up and release so there's 24 hours to finalise the name. Here's the names I like thus far: DateTime::LazyInit (from John Siracusa) DateTime::Mock (from Joshua Hoblitt) DateTime::Diet (original development name based on the subject) If anyone has any interest, please comment in the next 24 hours (based on the timestamp of this message) I'm not trying to beat this thread to death but it just occurred to me that this is following the proxy design pattern. So DateTime::Proxy might be a good name as well. Of the three name in your list I think I like DateTime::LazyInit more than the others. Cheers, -J -- pgpRyOZFJZvo4.pgp Description: PGP signature
Re: DateTime.pm on a Diet
Quoting Rick Measham [EMAIL PROTECTED]: Joshua Hoblitt wrote: What about DateTime::Mock? Since that would make it clear that this isn't /really/ a DT object. Thanks Joshua, I want to wrap this up and release so there's 24 hours to finalise the name. Here's the names I like thus far: DateTime::LazyInit (from John Siracusa) DateTime::Mock (from Joshua Hoblitt) DateTime::Diet (original development name based on the subject) +1 for LazyInit for plain-spokenness -1 on the Mock, since that implies it is for testing and needs you to stub out the code. +1 for Diet (it has more cheek)
Re: DateTime.pm on a Diet
On 21 Jul 2005, at 15:51, [EMAIL PROTECTED] wrote: Quoting Rick Measham [EMAIL PROTECTED]: Joshua Hoblitt wrote: What about DateTime::Mock? Since that would make it clear that this isn't /really/ a DT object. Thanks Joshua, I want to wrap this up and release so there's 24 hours to finalise the name. Here's the names I like thus far: DateTime::LazyInit (from John Siracusa) DateTime::Mock (from Joshua Hoblitt) DateTime::Diet (original development name based on the subject) +1 for LazyInit for plain-spokenness -1 on the Mock, since that implies it is for testing and needs you to stub out the code. [snip] Ditto. Adrian
Re: DateTime.pm on a Diet
DateTime::LazyInit (from John Siracusa) has received the most votes by far, so I'll go with it. As one respondant put it, it has 'plain spokenness' DateTime::Diet, the other name to recieve some votes, made me think of 'DateTime::Lite', and it isn't -- it's full-blown DateTime, just not immediately. I'll release sometime over the weekend, once I get tests and docs writtem. Cheers! Rick Measham
Re: DateTime.pm on a Diet
Joshua Hoblitt wrote: What about DateTime::Mock? Since that would make it clear that this isn't /really/ a DT object. Thanks Joshua, I want to wrap this up and release so there's 24 hours to finalise the name. Here's the names I like thus far: DateTime::LazyInit (from John Siracusa) DateTime::Mock (from Joshua Hoblitt) DateTime::Diet (original development name based on the subject) If anyone has any interest, please comment in the next 24 hours (based on the timestamp of this message) Cheers! Rick Measham
Re: DateTime.pm on a Diet
On Thu, 21 Jul 2005, Rick Measham wrote: Joshua Hoblitt wrote: What about DateTime::Mock? Since that would make it clear that this isn't /really/ a DT object. Thanks Joshua, I want to wrap this up and release so there's 24 hours to finalise the name. Here's the names I like thus far: DateTime::LazyInit (from John Siracusa) I think I like this one best. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm on a Diet
Dave Rolsky wrote: It has a pretty different API, in that it's new() constructor accepts anything without validation. I suppose it could check for extra args and call DateTime::Fat-new() if needed. Can we split the existing new() into validation vs. object creation and share it between the two equally (no, I haven't looked at the source)? Thus, the lightweight new() could validate by default, but offer a quick no_validate = 1 option for the people creating objects out of databases (prevalidated). It may be once that you are slinging lightweight objects around most of the time, the performance drain due to validation won't be quite as noticible. I think that'd be a possibility, but it'd have to pass the DateTime.pm test suite in that case. That's certainly where I was considering starting (with the test suite). It might also be a good experiment to see where the performance issues really are. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: DateTime.pm on a Diet
On Thu, 7 Jul 2005, Rick Measham wrote: Dave Rolsky wrote: It has a pretty different API, in that it's new() constructor accepts anything without validation. I suppose it could check for extra args and call DateTime::Fat-new() if needed. I think that'd be a possibility, but it'd have to pass the DateTime.pm test suite in that case. We'd need to bring complete validation back in though. Otherwise your object dies unexpectedly later on: $dt = DateTime::Diet-new( year = 2004, month = 232 ); print $dt-year; #2004 print $dt-month; #232 print $dt-monthname; # DIE: Illegal value passed to DateTime::new Yeah, this occurred to me after I wrote that. Having these sorts of delayed errors is very bad and surprising for users. Rick's code is well suited to instances where you have data that you've already checked, but not so good for general purpose usage. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm on a Diet
On 7/7/05 12:12 AM, Rick Measham wrote: Dave Rolsky wrote: DateTime::Shim DateTime::Trampoline DateTime::ThinShim DateTime::Proxy DateTime::Diet - not awful but a little cute, methinks ;) Of the above, I still like DT:Diet. If you want something less cute/more serious how about: DateTime::FastConstructor The others listed above don't seems to convey the purpose of the module. I'll throw a few names out: DateTime::Delayed DateTime::AutoLoaded DateTime::LazyInit -John
Re: DateTime.pm on a Diet
On Wed, 6 Jul 2005, Rick Measham wrote:
I've included the output of the attached script below. I was surprised to
note that even after the rebless was included in the tests, the Diet version
was still *much* quicker.
I'm not sure what you mean. It's much quicker for operations that occur
before the rebless. If you were to keep using that object for further
operations, the speed increase given from calling one diet method would
fade into background noise.
For example:
timethese(1,
{
' DateTime' =
sub { my $dt = new DateTime( year = 2004 );
my $day = $dt-day;
$dt-set_minute(22);
$dt-datetime;
for ( qw( year month hour day minute second nanosecond ) ) {
my $foo = $dt-$_();
}
$dt-set_minute(30);
for ( qw( year month hour day minute second nanosecond ) ) {
my $foo = $dt-$_();
}
},
'DateTime::Diet' =
sub { my $dt = new DateTime::Diet( year = 2004 );
my $day = $dt-day;
$dt-set_minute(22);
$dt-datetime;
for ( qw( year month hour day minute second nanosecond ) ) {
my $foo = $dt-$_();
}
$dt-set_minute(30);
for ( qw( year month hour day minute second nanosecond ) ) {
my $foo = $dt-$_();
}
},
});
I get these results:
Benchmark: timing 1 iterations of DateTime, DateTime::Diet...
DateTime: 8 wallclock secs ( 8.26 usr + 0.00 sys = 8.26 CPU) @
1210.65/s (n=1)
DateTime::Diet: 7 wallclock secs ( 6.44 usr + 0.00 sys = 6.44 CPU) @
1552.80/s (n=1)
So it still has an impact, but it's starting to become less and less
significant.
But this might be useful for cases where people have to create lots of
objects, they don't care about time zones, and they rarely have to use the
advanced DT.pm methods (math, time zones, etc).
I suspect people would want to be able to use this in conjunction with a
parser like DT::Format::MySQL or something, where they know the data in
the DB represents real datetimes.
That's not currently possible, but it could be added to the generic
DT::Format::* API spec.
-dave
/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg. My book blog
===*/
Re: DateTime.pm on a Diet
Geoffrey, if you're reading this, I'd love your comments on how useful this would be in your case. I am :) ok, I haven't looked at the code yet, but from your explanations it sounds attractive, especially in our situation. just like you, we don't necessarily need data validation since the data is coming mostly from database date/time fields. also similarly we would be creating objects for sql fields that may be infrequently manipulated in the codebase itself. so, take the overhead out of those kinds of things and you've made half my case for me :) the only sticking point would be the date math exceptions dave mentions. in my particular situation we deal with slices of time - the exact time of an event, when that event is visible on the web, what that time looks like to our servers on the west coast versus data entry on the east coast versus an attendee in australia, etc - so it's the date math that is driving force behind using DateTime in the first place. in essence, optimize away, but exploding object size when you need to do something real with it isn't much of a win. anyway, I hope you guys are taking my opinions appropriately - DateTime is clearly the right choice for perl DT logic IMHO for a variety of reasons, but I wasn't able to convince others to adopt it since their criteria for right choice was significantly different. so it's their arguments and mindset that I'm trying to convey :) --Geoff
Re: DateTime.pm on a Diet
Le 5 juil. 05 à 15:15, John Siracusa a écrit : On 7/5/05 7:04 AM, Eric Cholet wrote: A while ago we did some profiling of an app that uses DateTime extensively and found out that most of the time is spent in Params::Validate. I understand this is somewhat of a religious issue, but in this case it's a net loss for us: the params have been validated zillions of times, and we lose performance in production. I would love a DateTime sans param validation. Have you tried turning off the validation by setting the PERL_NO_VALIDATION environment variable? John, thanks for the pointer. I see this is documented in Params::Validate. I'd never thought of looking in Params::Validate docs to find out how to disable DateTime's use of it. It might be useful to include a pointer to this feature in DateTime's docs. -- Eric Cholet
Re: DateTime.pm on a Diet
I've used this approach in Date::Set. It runs the same test suite of DateTime::Event::ICal, in one third of the time. - Flavio S. Glock 2005/7/6, Rick Measham [EMAIL PROTECTED]: DateTime::Diet (attached) is a simple wrapper around DateTime that handles simple new(), set() and get methods. If you ask it for something it can't handle by itself, it reblesses your object into full DateTime and then calls the method on the DateTime object.
Re: DateTime.pm on a Diet
On Wed, 6 Jul 2005, John Siracusa wrote:
If you're going for speed, there's more low-hanging fruit to be had.
Check
out my modifications in DateTime::Diet2 (attached).
Dave Rolsky wrote:
Yeah, I was thinking that we'd do something like this if we're going to
turn this into an officially blessed implementation. I was assuming
Rick just used AUTOLOAD for a quick proof of concept.
I was .. however, as Dave later suggests, I'd planned on actually
creating the subs as perl subs .. not even having the overhead of the
autocreation in BEGIN.
..
sub minute { return $_[0]-{minute} || 0 }
..
So .. would this module actually get used by anyone but me? If so I'll
go ahead and polish it off.
Cheers!
Rick Measham
Re: DateTime.pm on a Diet
On Thu, 7 Jul 2005, Rick Measham wrote: So .. would this module actually get used by anyone but me? If so I'll go ahead and polish it off. It sounded like people were interested. And maybe it's a if you build it they will come thing ;) Anyway, go for it and let's brainstorm on a better namespace. Here's some thoughts: DateTime::Shim DateTime::Trampoline DateTime::ThinShim DateTime::Proxy DateTime::Diet - not awful but a little cute, methinks ;) -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
Re: DateTime.pm on a Diet
Dave Rolsky wrote: It sounded like people were interested. And maybe it's a if you build it they will come thing ;) Anyway, go for it and let's brainstorm on a better namespace. Here's some thoughts: At the risk of sounding flippant, why not rename the existing DateTime class to DateTime::Fat (or the less inflamatory DateTime::Base) and put the proposed module in it's place as DateTime. If it is designed well, everything should Just Work(TM) with the shim class, which should always be faster than the existing class, even with the extra dispatch to plump up the object when needed. John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747
Re: DateTime.pm on a Diet
On Wed, 6 Jul 2005, John Peacock wrote: At the risk of sounding flippant, why not rename the existing DateTime class to DateTime::Fat (or the less inflamatory DateTime::Base) and put the proposed module in it's place as DateTime. If it is designed well, everything should Just Work(TM) with the shim class, which should always be faster than the existing class, even with the extra dispatch to plump up the object when needed. At first I thought this might be a good idea .. Dave Rolsky wrote: It has a pretty different API, in that it's new() constructor accepts anything without validation. I suppose it could check for extra args and call DateTime::Fat-new() if needed. I think that'd be a possibility, but it'd have to pass the DateTime.pm test suite in that case. We'd need to bring complete validation back in though. Otherwise your object dies unexpectedly later on: $dt = DateTime::Diet-new( year = 2004, month = 232 ); print $dt-year; #2004 print $dt-month; #232 print $dt-monthname; # DIE: Illegal value passed to DateTime::new This needs to be an *alternate* rather than standard way of creating DateTime objects, and the documentation will basically just tell you that you need to be very aware of the lack of immediate validation. Cheers! Rick Measham
Re: DateTime.pm on a Diet
Dave Rolsky wrote: DateTime::Shim DateTime::Trampoline DateTime::ThinShim DateTime::Proxy DateTime::Diet - not awful but a little cute, methinks ;) Of the above, I still like DT:Diet. If you want something less cute/more serious how about: DateTime::FastConstructor The others listed above don't seems to convey the purpose of the module. Cheers! Rick Measham
Re: DateTime.pm on a Diet
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
Re: DateTime.pm on a Diet
Le 4 juil. 05 à 19:47, Dave Rolsky a écrit : 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. A while ago we did some profiling of an app that uses DateTime extensively and found out that most of the time is spent in Params::Validate. I understand this is somewhat of a religious issue, but in this case it's a net loss for us: the params have been validated zillions of times, and we lose performance in production. I would love a DateTime sans param validation. -- Eric Cholet
Re: DateTime.pm on a Diet
On 7/5/05 7:04 AM, Eric Cholet wrote: A while ago we did some profiling of an app that uses DateTime extensively and found out that most of the time is spent in Params::Validate. I understand this is somewhat of a religious issue, but in this case it's a net loss for us: the params have been validated zillions of times, and we lose performance in production. I would love a DateTime sans param validation. Have you tried turning off the validation by setting the PERL_NO_VALIDATION environment variable? I agree with Dave that moving big/numerous data structures from Perl to C will have the most bang for the buck: On 7/4/05 1:47 PM, Dave Rolsky wrote: Implementing time zones in XS as native C data structures would almost certainly be a huge win. Beyond that, the biggest culprits will probably be what they always are in non-compute-intensive Perl: function/method call overhead and memory management overhead. Reduce the number of subs that are called and reduce the size and number of allocations/deallocations and then you might start to get closer to the point where actual calculations start to become visible in the profile. -John
