Xaprb

Stay curious!

JavaScript date formatting benchmarks

with 10 comments

If you have questions or comments or bugs report, or a change to make, be sure to use the project’s new homepage: Flexible JS Formatting Libraries

Two earlier articles demonstrated how to format and parse dates flexibly with JavaScript. I asserted in those articles that my approach was efficient, though I didn’t provide any numbers to prove my claim. This article compares the performance of my date-formatting library against several other date-formatting libraries I’ve found online.

I’d like to benchmark my date-parsing library too, but I haven’t seen any comparable implementations. By the way, my date-formatting and date-parsing libraries are wrapped into a single file, so even though I’m not actually executing the date-parsing functions in this benchmark, they’re compiled anyway.

Motivation

My motivation for this article is simply to demonstrate the truth of what I said earlier: writing code to write code can be very efficient. I’m explicitly not trying to say I’m “better” than anyone, or someone else does anything “wrong” or anything like that. This series of articles really isn’t even about date manipulation! It’s about demonstrating a programming technique: write a function that can write other functions, making it possible to optimize code whose behavior depends on input that is not known until runtime. That’s why my first date-formatting article was originally titled “JavaScript closures for runtime efficiency.”

Note that my motivation also isn’t to make the fastest date formatting code. I haven’t really tried to optimize for speed, but if I wanted to, I think I could probably find some bottlenecks and optimize my own code further.

All I’m trying to do is demonstrate the general coding methodology I used, because I often see folks using a much less optimal solution, probably because they don’t know about (or aren’t comfortable with) dynamic code generation. That’s just my opinion.

Setup

I ran these benchmarks on Firefox 1.5.0.2 on my home computer, a fairly new and powerful AMD64 machine running Gentoo GNU/Linux. I won’t bother telling you all the hardware specs… that always makes my eyes glaze over.

I created a set of pages that do nothing but include the JavaScript files needed, and run 100,000 iterations of date-formatting. I closed my browser window between each test, and nothing else was running on my machine. I ran each test several times and averaged the results, rounding to four significant digits.

I had to increase the script timeout so Firefox wouldn’t interrupt the tests. I did this by opening about:config, then changing dom.max_script_run_time to 5000 seconds.

Results

Here’s a graph of the times. The algorithms are in alphabetical order:

JavaScript date-formatting benchmark

Obviously, the method I use is much faster — between 3.15 and 4.89 times faster. Here are the results as numbers in a table. WARNING: If you click on the links to the benchmarks, your browser will probably freeze for the better part of a minute on a fast machine — maybe longer on a slow machine.

Is this an apples-to-apples comparison?

Absolutely not, and if it were, the slowness of the other methods would be even more obvious.

First of all, I’m only testing a single method of formatting — producing a date in YYYY-MM-DD format. I also haven’t been scientific enough to really be accurate.

Beyond that, though, these various bits of code I’ve benchmarked are vastly different. The one that provides the most similar formatting functionality to mine is Svend Tofte’s (that’s probably why it’s the slowest), but even that one only does parsing, not formatting (mine does both). The others are much less fully-featured, which means they’d probably be even less performant if someone extended them to implement the same set of functionality.

As I said above, I’m not doing this to pick on anyone, but the Dojo method is probably the least efficient. It’s the simplest of all, providing only a few formatting characters, and it’s not really that much faster than Svend Tofte’s implementation. It’s probably so slow because it a) uses lots of if statements and b) uses repeated string replacements with regular expressions. This is just a hunch, but if it had the rich feature set of my implementation or Svend Tofte’s, I think it would probably be the slowest by far.

Written by Xaprb

May 14th, 2006 at 6:45 pm

Posted in Uncategorized

«
»

10 Responses to 'JavaScript date formatting benchmarks'

Subscribe to comments with RSS

  1. Hello, it was interesting seeing this test (though disheartening to see my code was the slowest). I went back to read what this “amazing” technique was, and yes, that’s a novel thing to do in JS! :)

    I respect that this is not a diss on anyone (I could have written, and probably have, much worse crap on my own site), but I have to admit, I take objection to these other solutions as “much less optimal”. Optimality is a hard thing to gauge, and I would firmly argue that speed is usually not of the essence in JS.

    Dynamic code generation is no simple thing, to be glossed over, and significantly increases the complexity of the code. And for the most part, I do like to keep my JS simple (I’ve yet to actually use any JS lib, maybe my less, but well).

    But it’s nice to be reminded of the fact that code-generation is available, should you choose if suitable (with the client tier becoming more heavy, this is probably already happening all over the world).

    Svend Tofte

    14 Jun 06 at 4:00 am

  2. Svend,

    Thanks for writing in. I wrote:

    All I’m trying to do is demonstrate the general coding methodology I used, because I often see folks using a much less optimal solution…

    Even though it sounds like it, I didn’t mean to say the other JS date-formatting systems were less optimal. I was again speaking about general application of code-generation techniques. I have seen other situations where code generation would be the best solution by far, but a programmer has avoided it, or as I speculate, the idea may not have even occurred to the programmer.

    I agree with you that optimality is hard to gauge. I disagree that the code complexity is increased. I think code generation can significantly decrease complexity in many cases.

    If it takes a few lines of code to write something that can make decisions at runtime, that’s a lot less complexity than hard-coding all possible decisions. Once those few lines are debugged and working, every decision is correctly handled at runtime; on the other hand, if every decision is hard-coded, every single one has to be debugged separately. There are a couple dozen date-formatting characters. Each one, if hard-coded, is susceptible to typos and edge cases, etc etc.

    The general pattern I’m trying to point out in this comment is how to view the code from a higher level and abstract away from it, writing a machine to solve the tedious stuff. I think doing that can vastly simplify the code. Sometimes it’s much easier to solve a general problem than dozens of specific ones.

    Back to specifics, your date-formatting code is actually a tiny bit longer than mine. I stripped comments and empty lines, and took the date-parsing code out of mine, leaving only the formatting code:

    wc date-functions.js formatDate.js 
  209   719  6128 date-functions.js
  216   927  7439 formatDate.js

    Again, that doesn’t prove anything about code complexity, just like the benchmarks above don’t prove anything about optimality, but I think it’s impossible to say code generation “significantly increases the complexity of the code” across the board.

    Speed does matter sometimes. Sometimes it doesn’t, and when it doesn’t, then other factors — maintainability, small code size, ease of deployment, etc etc — are obviously to be striven for. In every coding project, getting the priorities straight is the first priority. But if you were writing a JavaScript spreadsheet, which is a hot topic these days, speed would matter hugely.

    Finally, your code isn’t the slowest. The tests aren’t apples-to-apples comparisons. The dojo code is the slowest. If the dojo code implemented three dozen formatting instructions, it would be enormously slow.

    Xaprb

    14 Jun 06 at 8:41 am

  3. [...] format – The date format for the editor. It supports only numeric based date formats, no text. For example, mm/dd/yy, dd.mm.yyyy, yyyy-mm-dd are all valid formats, but MMM dd, yyyy is not. The format is now identical to PHP date() and text is allowed. Credit for that goes to this fantastic date library. This format is for the editor only and doesn’t affect the rendering of the cell when not in edit mode. Your rendering function can use any date format it wants. [...]

    Jack Slocum’s Blog » Adding built-in editing support to the Yahoo! UI Extensions Grid

    12 Sep 06 at 2:57 am

  4. What not all recognize is that optimality too is a relative term, relative to what you optimize for. Speed, code size and memory footprints being common, I think it’s unfortunately often more important to javascript programmers that a neophyte programmer would feel instantly at home with your approach to problem solving, which isn’t going to happen with high quality code on an abstraction level where usually only people with a lisp or functional programming background move.

    It’s great to see the YUI grid above adopt your approach, and it’s been both very rewarding and refreshing reading your articles. Few recognize and actually make good use of the dynamic aspect of javascript like this, and it’s very commonplace to be defensive of one’s own choices when presented with someone elses. I hope I would have received your article more openhandedly, had I written either of the other comparison targets.

    Johan Sundström

    13 Sep 06 at 5:52 am

  5. I’m glad to see a good use for it too. Up till now it’s mostly been a solution in search of a problem (the actual product, that is… the “technique demo” is practical itself, from my point of view).

    Writing such an article as this is difficult for me to do gracefully, and I don’t always strike the right balance. If it’s hard for me to do that, how much harder is it for the people with longer bars in the graph to gracefully react? If I were the creator of one of those longer bars, I can only hope I’d receive this article openhandedly. But I understand if they don’t. Thanks for writing in.

    Xaprb

    13 Sep 06 at 8:42 am

  6. [...] great example is the Behaviour JavaScript library, and the techniques it encourages. Or my own JavaScript date formatting and parsing library, which are not only clearer and simpler to use than their alternatives, but much more powerful and [...]

    Five great Perl programming techniques to make your life fun again « Jfree’s dreaming

    8 Oct 07 at 9:33 pm

  7. This project’s new home page is at http://code.google.com/p/flexible-js-formatting/

    Xaprb

    2 Oct 08 at 10:24 am

  8. [...] JavaScript date formatting benchmarks: An interesting and novel blog post from 2006. [...]

    Pathfinder Development » 37 JavaScript benchmarks

    18 Dec 08 at 12:38 am

  9. I wonder how jPaq’s Date.prototype.format function would compare to the other functions. Documentation for this function can be found here: http://jpaq.org/documentation/Date.prototype.format%28%29/1.0/. The best thing about the library is the fact that you can download your own build which contains only the code that you will need.

    Clarence Fredericks

    7 Feb 11 at 12:42 pm

  10. One more comment linking to that library, and I spam them all… twice was enough :-)

    Xaprb

    7 Feb 11 at 1:01 pm

Leave a Reply