From: Josef S. <jos...@we...> - 2009-11-18 16:27:47
|
Why don't we use POSIX and mktime to get the unix time stamp? I did a quick performance test. I did some benchmark in Prices.pm. Sort the prices by date. =cut sub sort { my ($self) = @_; use Benchmark; my $t0 = Benchmark->new; # ... your code here ... my @prices = sort { Finance::GeniusTrader::DateTime::map_date_to_time($self->timeframe, $a->[$DATE]) <=> Finance::GeniusTrader::DateTime::map_date_to_time($self->timeframe, $b->[$DATE]) } @{$self->{'prices'}}; $self->{'prices'} = \@prices; my $t1 = Benchmark->new; my $td = timediff($t1, $t0); open(IN,'>', "/tmp/geniustrader-DEBUG"); print IN timestr($td); close IN; #print "the code took:",timestr($td),"\n"; } And changed timelocal to mktime in package Finance::GeniusTrader::DateTime::Day use Finance::GeniusTrader::DateTime; #ALL# use Log::Log4perl qw(:easy); use Time::Local; use POSIX; =head1 Finance::GeniusTrader::DateTime::Day This module treat dates describing a day. They have the following format : YYYY-MM-DD =cut sub map_date_to_time { my ($date) = @_; my ($y, $m, $d) = split /-/, $date; ($d) = split / /, $d; #return timelocal(0, 0, 0, $d, $m - 1, $y - 1900); return mktime(0, 0, 0, $d, $m - 1, $y - 1900); } Running with timelocal: time $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse- workspace/geniustrader/own-scripts/graphic/graphic_examples.conf IBM > foobar.png real 0m15.139s user 0m10.557s sys 0m2.096s and 3 wallclock secs ( 1.10 usr + 0.66 sys = 1.76 CPU) Running with mktime: time $HOME/eclipse-workspace/geniustrader/script/graphic.pl --file $HOME/eclipse- workspace/geniustrader/own-scripts/graphic/graphic_examples.conf IBM > foobar.png real 0m11.554s user 0m8.489s sys 0m1.104s and 1 wallclock secs ( 0.38 usr + 0.30 sys = 0.68 CPU) Am Mittwoch 18 November 2009 schrieb Thomas Weigert: > This is a complicated problem. On the one hand, speed of time > conversions during the run is critical, as when time GT maps between > timeframes or does time comparisons it often invokes this function. On > the other hand, the fastest time functions don't work for times outside > of the epoch. > > The conclusion was that the most important need for GT is for market > data from within the epoch. But the price to be paid is that one cannot > do long time studies that start for in the past (the future is less of a > problem due to the lack of market data). > > The best way to handle might be to make the time conversion dependent on > the time frame. If one works with yearly data, maybe it is ok to use > slower functions, and typically, when one analyzes the market over 100 > years one probably will use yearly data? But in either way, today you > need to stick to the epoch. > > Th. > > Chia-liang Kao wrote: > > Hi Josef, > > > > 1960 is before epoch, and time::local wouldn't be able to support > > that. neither would it support years > 2038. We'll need to migrate to > > something like Time::y2038 or DateTime. > > > > 2009/11/18 Josef Strobel <jos...@we...>: > >> Hi all, > >> > >> I tried to load a time series where the start date is before 1960-12-31, > >> but I always get the following error: > |