ThirdBase is a replacement for Ruby’s standard Date/DateTime
classes, with the following differences:
- ThirdBase is roughly 2-10 times faster depending on usage
- ThirdBase has a lower memory footprint
- ThirdBase supports pluggable parsers
- ThirdBase doesn’t depend on Ruby’s Rational class
- ThirdBase always uses the gregorian calendar
The 1.2.0 release of ThirdBase makes it much easier to add custom
parsers. Custom parsers can now be specified via a strptime
format string:
DateTime.add_parser(:us, ‘%Z %m~%Y~%d %S%M%H’)
DateTime.parse(‘PDT 02~2009~28 154512’)
=> #<DateTime 2009-02-28T12:45:15-07:00>
With a strptime-based parser, you don’t need to provide a block,
as the parser block is created for you.
You can still use the old Regexp-style parsers, and now they can
return a Date/DateTime instance directly, they are no longer
required to return a hash that is given to new!.
An additional default parser was added so the following can be
handled correctly:
DateTime.parse(Time.now.to_s)
DateTime.parse(Time.now.strftime(‘%+’))
The named timezones supported by Ruby’s Time class are now
supported by ThirdBase (e.g. PST, EDT, UTC).
The %z strptime/strftime format string modifier now operates more
closely to standard ruby.
Enjoy,
Jeremy
ThirdBase is a replacement for Ruby’s standard Date/DateTime
classes, with the following differences:
- ThirdBase is roughly 2-10 times faster depending on usage
How does it compare to http://tomayko.com/src/date-performance/
?
Thanks.
-r
Roger P. wrote:
ThirdBase is a replacement for Ruby’s standard Date/DateTime
classes, with the following differences:
- ThirdBase is roughly 2-10 times faster depending on usage
How does it compare to http://tomayko.com/src/date-performance/
I haven’t used Date::Performance, but from reading that page,
Date::Performance would certainly be faster as it is implemented in C.
ThirdBase is pure ruby code.
ThirdBase uses customizable regexp-based parsers as opposed to a fixed
string scanning parser, so it is probably more flexible.
I can’t comment in more detail without reading the Date::Performance
code.
Jeremy
On Mon, Aug 17, 2009 at 7:59 PM, Jeremy E.[email protected]
wrote:
ThirdBase is pure ruby code.
ThirdBase uses customizable regexp-based parsers as opposed to a fixed
string scanning parser, so it is probably more flexible.
I can’t comment in more detail without reading the Date::Performance
code.
Both Date::Performance and ThirdBase seem to focus on the performance
of datetime parsing.
I took a quick look at the Date::Performance code, and it definitely
is taking the approach of re-implementing a few key methods in C. I
suspect that most of the performance comes from calling the Clib
strptime routine, less so from the ‘ruby-inlined’ methods.
In implementing RiCal GitHub - rubyredrick/ri_cal: New Rfc 2445 (iCalendar) gem for Ruby
my main performance problem with datetime was date time calculations.
Because of the standard datetime implementation using a rational
fraction to represent the time-of-day portion of a datetime the
performance profiles were dominated by the gcd calculations needed to
reduce rational numbers.
So in my case I replaced the internal use of datetime instances with a
custom class which uses a normal Ruby date and a fixnum representing
the number of seconds since the beginning of the day, no C code, all
ruby and much much faster for my purposes.
But not at all a general replacement for datetime.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale
Rick Denatale wrote:
Both Date::Performance and ThirdBase seem to focus on the performance
of datetime parsing.
ThirdBase doesn’t just focus on parsing speed. It also tries to be fast
to instantiate and fast for calculations.
In addition to performance, ThirdBase also makes the parsers for
Date.parse/DateTime.parse easily modifiable for the user.
I took a quick look at the Date::Performance code, and it definitely
is taking the approach of re-implementing a few key methods in C. I
suspect that most of the performance comes from calling the Clib
strptime routine, less so from the ‘ruby-inlined’ methods.
In implementing RiCal GitHub - rubyredrick/ri_cal: New Rfc 2445 (iCalendar) gem for Ruby
my main performance problem with datetime was date time calculations.
Because of the standard datetime implementation using a rational
fraction to represent the time-of-day portion of a datetime the
performance profiles were dominated by the gcd calculations needed to
reduce rational numbers.
So in my case I replaced the internal use of datetime instances with a
custom class which uses a normal Ruby date and a fixnum representing
the number of seconds since the beginning of the day, no C code, all
ruby and much much faster for my purposes.
ThirdBase takes a slightly different approach. It stores the date in
whatever the input format is, converting only when necessary (which is
why it is fast to instantiate). When it does need to do calculations,
it generally converts to an integer julian day number and a Float
representing the fraction of the day.
But not at all a general replacement for datetime.
ThirdBase can be used as a general replacement. Not everything works
the same way, but the differences are documented and won’t affect most
code.
Jeremy