

Ruby's Date/DateTime classes rewritten in C.. 20-200x perf improvement - stanislavb
http://github.com/jeremyevans/home_run
Fast Date/DateTime classes for ruby. By just installing the home_run gem/lib you'll get an amazing performance increase!
======
hopeless
Too often these types of optimisation ignore the actual real world usage but
credit to the author for showing that it can seriously improve ActiveRecord
performance (albeit 3-4x speedup rather than 200x). I have some Date-intensive
models so I might consider using this.

------
j-g-faustus
I got something like a 10x performance improvement (for custom code parsing
stock quotes from CSV) merely by rewriting Ruby's Date class in Ruby. The
default Ruby Date implementation is awfully slow.

~~~
weaksauce
Any idea on what edge cases you might be missing out on that would make your
version X times faster? Or, why their version is so slow?

~~~
psadauskas
Date.parse is really incredibly slow, because it tries all the format parsers
until it get one that works. If the format you're trying to parse is low in
that list, its going to be very slow.

If you know your format (iso8601, etc), you're better off just using the right
parser instead of Date.parse.

Also the internal representation uses Rational, which can be pretty slow
itself.

Date.parse:
[http://github.com/ruby/ruby/blob/trunk/lib/date/format.rb#L1...](http://github.com/ruby/ruby/blob/trunk/lib/date/format.rb#L1028)

edit: correction to how parse works.

------
binomial
I've been using Ryan Tomayko's date/performance library, which is pretty fast,
especially if you use it along with his date/memoize module.

<http://github.com/rtomayko/date-performance>

------
heresy
Despite the problems with the Date classes, I still think this is ultimately
the wrong approach.

Dropping to C at the slightest hint of a performance issue is a band-aid,
papering over deficiencies in the VM.

------
gregwebs
I hope this becomes a default at least for 1.8. The performance improvement is
less dramatic in Ruby 1.9

------
jpr
I don't get it. Isn't one of the major purposes of using higher level
languages to avoid writing in C?

~~~
parenthesis
"one of the major purposes of using higher level languages [is] to avoid
writing in C"

And one of the major purposes of using C is to write fast libraries that can
then be called from high level languages.

~~~
lsb
Alternately, if you use a high-level-language like Haskell that can compile
into machine code, you can rewrite something like regexp matching (like regex-
tdfa[1]) and get better performance than what the stdlib gives you on some
inputs.

[1]
[http://www.haskell.org/haskellwiki/Regular_expressions#regex...](http://www.haskell.org/haskellwiki/Regular_expressions#regex-
tdfa)

~~~
jrockway
Yeah, exactly. I rarely have to call out to C in my Haskell applications. When
I do, it's only to get or send data to a C library that I don't want to
rewrite.

Internally, things like Data.Vector work just like the C equivalent. The
internal representation of the data is the same (i.e., Vector.Unboxed Double
== a big block of memory with CDoubles in it), and the machine instructions
that run on the data are the same.

High-level languages need not be slow. It's just that Perl, Python, Ruby, and
PHP are.

------
2mt_stephan
Which is excellent if your primary use case is dealing with millions of date
operations.

