Re: DateTime::Lite
On Sat, 22 Nov 2008, Daisuke Maki wrote: I have an RFC/request for blessing for a module. So my thought is go ahead, but can you call it DateTimeX::Lite? Basically, I'm worried that people will expect your module to work just like DateTime, but since they won't share a common code base going forward, that may not be the case. /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: DateTime::Lite
sure thing. as an aside, it's very unlikely I'll finish this up this year... too busy trying to startup a Perl oraganization here in Japan /and/ writing a book... --d Dave Rolsky wrote: On Sat, 22 Nov 2008, Daisuke Maki wrote: I have an RFC/request for blessing for a module. So my thought is go ahead, but can you call it DateTimeX::Lite? Basically, I'm worried that people will expect your module to work just like DateTime, but since they won't share a common code base going forward, that may not be the case. /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: DateTime::Lite
On Sat, 22 Nov 2008, Daisuke Maki wrote: =item Non-essential methods are loaded on demand A lot of times you don't even need to do date time arithmetic, for example. These methods are separated out onto a different file, so you need to load it on demand. use DateTime::Lite qw(Arithmetic); use DateTime::Lite qw(Strftime); Have you actually benchmarked the memory usage and compile speed for this stuff? I have a hard time imagining it really is all that slow, since it amounts to a few methods in each case. Singletons are okay, they serve a particular purpose. But besides being a memory hog of relative low benefit, when given the number of time zones are locales, they are just way too overwhelming for underlings. Could you explain this? What are you doing instead of singletons? Do you reload the time zone every time it's asked for? Also, that second sentence makes no sense ;) With this version, the objects are mostly the just plain objects, and the exact definition for each timezone/locale is stored in data files. What do the data files look like? If using them is faster than the current DT::TZ implementation, is there any reason we can't switch DT::TZ to use it? -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: DateTime::Lite
A lot of times you don't even need to do date time arithmetic, for example. These methods are separated out onto a different file, so you need to load it on demand. use DateTime::Lite qw(Arithmetic); use DateTime::Lite qw(Strftime); Have you actually benchmarked the memory usage and compile speed for this stuff? I have a hard time imagining it really is all that slow, since it amounts to a few methods in each case. Yes, I wrote a crude benchmark script in DateTime-Lite/tools/benchmar/load_times.pl If you don't load arithmetic and strftime, DT::Lite is twice as fast plain DT. Rate dt dt_lite_full dt_lite dt 46.6/s -- -13% -49% dt_lite_full 53.7/s 15% -- -41% dt_lite 91.7/s 97% 71% -- And again, /I know/ this isn't that much of a practical problem, because the engineer's correct answer is if the load time is slow, load it once, and use some sort of persistent environment. This is mainly a marketing issue to my audience, who, for example, includes CGI developers (i.e., persistent environment isn't an option). BTW, dt_lite_full is almost equivalent to using DateTime.pm, but I /think/ the difference comes from the tweak I did to switch method calls to function calls. That can probably be tweaked in DateTime.pm, if you want me to apply it. Singletons are okay, they serve a particular purpose. But besides being a memory hog of relative low benefit, when given the number of time zones are locales, they are just way too overwhelming for underlings. Could you explain this? What are you doing instead of singletons? Do you reload the time zone every time it's asked for? Also, that second sentence makes no sense ;) No, it's cached in memory, so in that sense they are singletons. However, they are all instances of the same DT::Lite::TimeZone object. When asked to load a time zone, I'm just require()ing a plain perl file, and shoving them to the constructor of DT::Lite::TimeZone. The timezone created is stored in a hash. Creating GVs for each timezone is a waste. Creating one class, then creating instances for each timezones are much cheaper. I discussed this briefly when I was trying to do DateTime::TimeZone::XS, but I got warnocked. With this version, the objects are mostly the just plain objects, and the exact definition for each timezone/locale is stored in data files. What do the data files look like? If using them is faster than the current DT::TZ implementation, is there any reason we can't switch DT::TZ to use it? I don't think DT::TZ will benefit anything from using my method, as they are true singletons. the data format isn't going to change anything. I'm not saying DT::TZ needs to change, either. If you want singletons that's just fine, but one of my requirements is to reduce the number of classes that needs to be installed. Again, /I know/ that installing data files instead of classes isn't any better, but I'd like to have a way to pick and choose which time zones the user wants to use/install, so they have the illusion of control over how much stuff is required to run DT::Lite. --d
Re: DateTime::Lite
On Tue, 25 Nov 2008, Daisuke Maki wrote: Yes, I wrote a crude benchmark script in DateTime-Lite/tools/benchmar/load_times.pl If you don't load arithmetic and strftime, DT::Lite is twice as fast plain DT. Rate dt dt_lite_full dt_lite dt 46.6/s -- -13% -49% dt_lite_full 53.7/s 15% -- -41% dt_lite 91.7/s 97% 71% -- And again, /I know/ this isn't that much of a practical problem, because the engineer's correct answer is if the load time is slow, load it once, and use some sort of persistent environment. This is mainly a marketing issue to my audience, who, for example, includes CGI developers (i.e., persistent environment isn't an option). BTW, dt_lite_full is almost equivalent to using DateTime.pm, but I /think/ the difference comes from the tweak I did to switch method calls to function calls. That can probably be tweaked in DateTime.pm, if you want me to apply it. Isn't this just a test of load times? How could using methods vs functions make any difference to a module's load times? I suspect the difference may come from several things: 1. Not loading several modules, including XSLoader and Params::Validate. 2. Not loading an XS component. 3. Not loading a default locale - DateTime ends up loading the en_US locale when DateTime.pm is loaded. Your benchmark might actually be _understating_ that, since your benchmark doesn't force this module to be reloaded as well. Creating GVs for each timezone is a waste. Creating one class, then creating instances for each timezones are much cheaper. I discussed this briefly when I was trying to do DateTime::TimeZone::XS, but I got warnocked. Right, I do remember that. Yes, it makes sense that not creating all those namespaces would reduce memory usage. I'm a little leary of changing things now, since it'd be backwards incompatible. I wonder if anyone actually relies on those objects having a namespace that includes the time zone though. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: DateTime::Lite
Isn't this just a test of load times? How could using methods vs functions make any difference to a module's load times? ah, well, um, I was still waking up when I wrote the email? Yes, it makes sense that not creating all those namespaces would reduce memory usage. I'm a little leary of changing things now, since it'd be backwards incompatible. I wonder if anyone actually relies on those objects having a namespace that includes the time zone though. As a programmer I'd say to hell with wasted memory, but as a product manager, I'd say keep it in the current state until you come up with a major upgrade (version 1.00, or something). At this point I'd rather see DateTime as a possibly heavy, but reliable reference point than to have its interface changed, so I can safely recommend DateTime.pm to anybody, while sneaking things like DT::Lite as a quick hack. --d
Re: DateTime::Lite
On Sat, 22 Nov 2008, Daisuke Maki wrote: Hi, I have an RFC/request for blessing for a module. So I have this requirement to make DateTime leaner, in terms of speed, load time, and the amount of memory consumed. The target is for casual users, so the use of XS code is not an option either. Doesn't Time::Piece (core in 5.10) already fill this niche? Ok, it doesn't do the locale and timezone stuff but IMO adding it there would make more sense than a DateTime::Lite. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
On Mon, 24 Nov 2008, Daisuke Maki wrote: No, for 3 reasons: 1. it's XS http://search.cpan.org/src/MSERGEANT/Time-Piece-1.13/Piece.xs Ok yes that would be a dealbreaker. Though if it is part of a default perl installation it is a lot less of a problem for casual users. 2. it would mean different API 3. as you say, it doesn't do everything DateTime can. I doubt if I am the only person who might ask this question. Perhaps you should add a comparison to Time::Piece to the POD? -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
I didn't notice so I didn't write this, but though Time::Piece may be in core, it's not in 5.8.x corelist -a Time::Piece 5.009005 1.11_02 5.01 1.12 If the argument there was Time::Piece has /always/ been in core, I would concede, but since it's only in the latest release, that would defeat my purposes as well. I doubt if I am the only person who might ask this question. Perhaps you should add a comparison to Time::Piece to the POD? Well, not that I'm trying to be terse... but I need DateTime, not Time::Piece. I need something that resembles DateTime, but faster, leaner, without XS. Time::Piece just wouldn't cut it. Since XS rules out Time::Piece, I still don't see why /not/? Is there any reason why? --d
Re: DateTime::Lite
On Mon, 24 Nov 2008, Daisuke Maki wrote: Well, not that I'm trying to be terse... but I need DateTime, not Time::Piece. I need something that resembles DateTime, but faster, leaner, without XS. Time::Piece just wouldn't cut it. Since XS rules out Time::Piece, I still don't see why /not/? Is there any reason why? Now that you have explained it I don't see why not either. However personally I have always thought of Time::Piece as DateTime 'lite' and I am guessing other people might too. So I think an explicit comparison in the docs would be useful. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: DateTime::Lite
Lite may pass the set of tests you extracted, but what about compatability with DateTime extensions like ::Set? I contend that the best way to tackle something like this and yield a more broadly useful Lite kit would be to get DateTime to use AutoSplit and/or subclass DateTime to override the chubbier bits. In my usage of DateTime, loading has never been the issue, but rather things like parameter validation and lack of memoization (friendliness). um, wait wait. Okay, so I don't want, nor intend to claim Datetime::Lite to be 100% API compatible with DateTime. I don't intend for DateTime::*** modules to use DateTime::Lite. This is for people who use the minimal aspects of DateTime, which is mainly to grab a date, do some calculation, and maybe print them out. But at the same time, I don't want Time::Piece (even if it was pure perl), but something that resembles DateTime, because 1. I want something that can (relatively) easily be replaced back to DateTime later. 2. I want something that is as full-featured as DateTime, so my audience don't start saying things like Well, using modules give you performance penalty, so let's /not/ use them at all! or Perl sucks, let's use because of petty performance problems. okay, so I'm starting to suspect that I didn't define my audience, and that's causing people to go WTF, another bad clone?. Perhaps that's what's Jaldhar is asking elsewhere in this thread. --d
Re: DateTime::Lite
Now that you have explained it I don't see why not either. However personally I have always thought of Time::Piece as DateTime 'lite' and I am guessing other people might too. So I think an explicit comparison in the docs would be useful. Thank you. I think I'm starting to see what was missing from my mission statement (or the lack thereof) --d
Re: DateTime::Lite
On Mon, 24 Nov 2008 02:36:53 +0900, Daisuke Maki wrote okay, so I'm starting to suspect that I didn't define my audience, and that's causing people to go WTF, another bad clone?. Perhaps that's what's Jaldhar is asking elsewhere in this thread. Your goals are clear. I welcome a DateTime::Lite pure Perl module that covers the basic needs of DateTime manipulation with minimal overhead. I don't expect full compatibility - hence the Lite. Thanks, Alex
Re: DateTime::Lite
On Sat, November 22, 2008 12:50 am, Daisuke Maki wrote:
So I have this requirement to make DateTime leaner, in terms of speed,
load time, and the amount of memory consumed. The target is for casual
users, so the use of XS code is not an option either.
In terms of speed, one of the things that's unique (AFAIK) to
DateTime is being able to thread-safely convert a datetime from
one timezone to another.
I'd be curious to know how it fares in this regard. Here's a
benchmark that for me shows DateTime proper almost ten times as
slow as non-thread-safely using libc routines (suggestions for
improvement enthusiastically welcomed):
#!/usr/bin/perl -l
use strict;
use warnings;
use DateTime;
use Env::C;
use POSIX mktime;
sub convert_timezone_datetime {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
my $dt = DateTime-new(year=$y, month=$mo, day=$d, hour=$h,
minute=$m, second=$s,time_zone=$tz);
$dt-set_time_zone($new_tz);
return map $dt-$_, qw/year month day hour minute second/;
}
sub convert_timezone_env_c {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
my $save_tz = Env::C::getenv(TZ);
Env::C::setenv(TZ,$tz,1);
my $time = POSIX::mktime($s,$m,$h,$d,$mo-1,$y-1900,0,0,-1);
Env::C::setenv(TZ,$new_tz,1);
POSIX::tzset(); # localtime_r bug
($s,$m,$h,$d,$mo,$y) = localtime($time);
$mo++; $y+=1900;
# this belongs in a destructor
if (defined $save_tz) { Env::C::setenv(TZ,$save_tz,1) }
else { Env::C::unsetenv(TZ) }
return ($y,$mo,$d,$h,$m,$s);
}
sub convert_timezone_system {
my ($y,$mo,$d,$h,$m,$s,$tz,$new_tz) = @_;
local $ENV{TZ} = $tz;
my $time = POSIX::mktime($s,$m,$h,$d,$mo-1,$y-1900,0,0,-1);
$ENV{TZ} = $new_tz;
POSIX::tzset(); # localtime_r bug
($s,$m,$h,$d,$mo,$y) = localtime($time);
$mo++; $y+=1900;
return ($y,$mo,$d,$h,$m,$s);
}
print join ,,
datetime=convert_timezone_datetime(2008,7,3,23,2,3,America/Denver,America/New_York);
print join ,,
registry=convert_timezone_env_c(2008,7,3,23,2,3,America/Denver,America/New_York);
print join ,,
system=convert_timezone_system(2008,7,3,23,2,3,America/Denver,America/New_York);
use Benchmark timethese;
timethese(-5, {
datetime = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_datetime(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
env_c = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_env_c(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
system = sub { my ($y,$mo,$d,$h,$m,$s) =
convert_timezone_system(2008,7,3,23,2,3,America/Denver,America/New_York);
return },
} );
Re: DateTime::Lite
On Sat, November 22, 2008 2:26 am, Daisuke Maki wrote: oops, forgot the SVN url http://svn.coderepos.org/share/lang/perl/DateTime-Lite/trunk Could we have a working tarball, please? I gave up after a very brief attempt to install and use Module::Install.
Re: DateTime::Lite
On Sun, Nov 23, 2008 at 9:45 AM, Alex Teslik [EMAIL PROTECTED] wrote: Your goals are clear. I welcome a DateTime::Lite pure Perl module that covers the basic needs of DateTime manipulation with minimal overhead. I don't expect full compatibility - hence the Lite. +1. I have lots of mostly command line scripts that use DateTime solely to print the current time etc. and have had to convert to something else when asked to make it portable or run with less memory etc. It'll be extremely useful if we can start writing code with DateTime and later replace the 'use' line with DateTime::Lite, or start writing with DateTime::Lite and later upgrade to DateTime when we need more complex stuff like Set or Calendar APIs. -- Tatsuhiko Miyagawa
Re: DateTime::Lite
http://users.endeworks.jp/~daisuke/DateTime-Lite-0.1.tar.gz As noted before, the timezone/locale stuff are not fully portable yet, so you need to be in the distro's root directory for DateTime::Lite to be usable. --d Yitzchak Scott-Thoennes wrote: On Sat, November 22, 2008 2:26 am, Daisuke Maki wrote: oops, forgot the SVN url http://svn.coderepos.org/share/lang/perl/DateTime-Lite/trunk Could we have a working tarball, please? I gave up after a very brief attempt to install and use Module::Install.
Re: DateTime::Lite
On Sun, November 23, 2008 9:09 pm, Daisuke Maki wrote: http://users.endeworks.jp/~daisuke/DateTime-Lite-0.1.tar.gz As noted before, the timezone/locale stuff are not fully portable yet, so you need to be in the distro's root directory for DateTime::Lite to be usable. Nice. 38% faster than DateTime at converting timezones. Can't wait for DateTime::Lite::XS (*ducks*)
Re: DateTime::Lite
Tatsuhiko Miyagawa wrote: It'll be extremely useful if we can start writing code with DateTime and later replace the 'use' line with DateTime::Lite, or start writing with DateTime::Lite and later upgrade to DateTime when we need more complex stuff like Set or Calendar APIs. This module seems to be a nice fit between my DateTime::Lazy and full-blown DateTime. To that end, it would be nice if there was a -to_datetime method that returned the same datetime as a DateTime object. Cheers! Rick Measham -- Message protected for iSite by MailGuard: e-mail anti-virus, anti-spam and content filtering. http://www.mailguard.com.au
DateTime::Lite
Hi, I have an RFC/request for blessing for a module. So I have this requirement to make DateTime leaner, in terms of speed, load time, and the amount of memory consumed. The target is for casual users, so the use of XS code is not an option either. I've done my share of hacking DateTime before, and I believe that changing the DateTime.pm code base itself is not really an option since DateTime needs to be backward compatible and what not. Instead I took the approach of using DateTime.pm as a reference implementation, and rearranged the code somewhat to get the desired effect. Now I have something that passes all current DateTime tests and named it DateTime::Lite. I intend to do some more hacking soon ish, but thought I'd ask for your comments before hand. I've pasted the current POD for DateTime::Lite at the end of this email. Also, if you are interested, the code is at note that the location of time zones and locales are hard coded now, so DateTime::Lite will only work from the checked out root. regards, --d =head1 NAMEDateTime::Lite - A Low Calorie DateTime =head1 SYNOPSIS use DateTime::Lite; my $dt = DateTime::Lite-new(year = 2008, month = 12, day = 1); $dt-year; $dt-month; $dt-day; $dt-hour; $dt-minuute; $dt-second; # Arithmetic doesn't come with DateTime::Lite by default use DateTime::Lite qw(Arithmetic); $dt-add( DateTime::Lite::Duration-new(days = 5) ); =head1 DESCRIPTION This is a complete rip-off of the great DateTime module. The author simply copy and pasted about 90% of the code, tweaked it and repackaged it. All credits go t o the original DateTime.pm's authors.However, this module was conceived out of a few specific desires : (1) Target those who do not need the full feature of DateTime.pm (2) Get better performance: * Reduce the amount of memory consumed, and * Reduce the time it takes to load the module (3) Make it easy to install on rental servers (4) Bundle everything in one distribution, including timezones and locales To achieve this, we've taken the original DateTime and rearranged it as follows: =over 4 =item DateTime::Lite is Pure Perl No XS, pronto. Since we expect the audience to be people who are not sysadmins, we don't expect them to have a full compiler support either.=item Parameter validation is done by hand =item Parameter validation is done by hand Params::Validate is a great module, but it slows things down. We don't see the merit of removing it from the original DateTime.pm, but we did so in this version. =item Non-essential methods are loaded on demand A lot of times you don't even need to do date time arithmetic, for example. These methods are separated out onto a different file, so you need to load it on demand. use DateTime::Lite qw(Arithmetic); use DateTime::Lite qw(Strftime); =item DateTime::Lite::TimeZone and DateTime::Lite::Locale DateTime::Lite::TimeZone and DateTime::Lite::Locale have big changes from their original counterparts. First, you do NOT call new() on these objects (unless this is something you explicitly want to do). Instead, you need to call load(). So if you were mucking with DateTime::Lite::TimeZone and DateTime::Locale, you need to find out every occurance of DateTime::Lite::TimeZone-load( name = 'Asia/Tokyo' ); and change them to DateTime::Lite::TimeZone-load( name = 'Asia/Tokyo' ); Singletons are okay, they serve a particular purpose. But besides being a memory hog of relative low benefit, when given the number of time zones are locales, they are just way too overwhelming for underlings. With this version, the objects are mostly the just plain objects, and the exact definition for each timezone/locale is stored in data files. # TODO: They can be located anywhere DateTime::Lite can find them TODO: We want to make it easy to pick and choose which locales/timezones to be available -- DateTime::TimeZone and Locale comes with the full-set, and normally we don't need this feature. For example, I only use Asia/Tokyo and UTC time zones for my dayjob. When we ask casual users to install a datetime package, we do not want to overwhelm then with 100+ timezones and locales. =cut
