Hacker News Reader

Comment by j-g-faustus | Hacker News Reader

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.

View on HN

Have you submitted that as a patch?

No, I implemented only the subset of the Date API I needed for the application. A fully-fledged Ruby Date would be a larger project.

+1 for duck typing, a custom non-Date object can look like a date for operations that only use a subset of the methods.

How many other people have half-started implementations of the same thing? That's why it's important to publish your code somewhere, even if it's "not good enough". Someone else can make it good enough.

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?

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...

edit: correction to how parse works.

I implemented just the subset of the Date API I needed for the application, so it didn't do conversions to other calendar formats (Julian/ordinal/commercial etc.).

I don't know why their version is so slow, I can only imagine that the conversion to Astronomical Julian Day (the Ruby Date internal representation) is expensive, inefficient or both.

I used year/month/day ints as internal representation, which was fast for my use cases (parse date string, format date string, compare two dates).

Reply on news.ycombinator.com