ANN: ThirdBase 1.2.0

[Jeremy Evans]

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_parserus, '%Z %m~%Y~%d %S`%M`%H')
DateTime.parse('PDT 02~2009~28 15`45`12')
=> #<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

- website {http://third-base.rubyforge.org/}

 

[Roger Pack]

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

 

[Jeremy Evans]

How does it compare to http://tomayko.com/src/date-performance/

I haven't used Date:erformance, but from reading that page,
Date:erformance 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:erformance
code.

Jeremy

 

[Rick DeNatale]

I haven't used Date:erformance, but from reading that page,
Date:erformance 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:erformance
code.

Both Date:erformance and ThirdBase seem to focus on the performance
of datetime parsing.

I took a quick look at the Date:erformance 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 http://github.com/rubyredrick/ri_cal/tree/master
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

 

[Jeremy Evans]

Both Date:erformance 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:erformance 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 http://github.com/rubyredrick/ri_cal/tree/master
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