So, I figured with a little capybara and a little therubyracer, I could test my javascript with real route calls. Let’s check it out.

The Javascript I want to test:

var dataObject = {};
var getRemoteData = function() {
  $.getJSON('/remote_path.json', function(data) {
    dataObject = $.parseJSON(data);
  });
}

We will pretend that hitting /remote_path.json returns the following response in JSON:

{ "my_information": "my response data" }

I want to test:

1. That /remote_path.json is accessible and returns information
2. That dataObject is populated with a Javascript Object containing the params I pass down

Here is my commented testing code:

  test 'get some information via ajax' do
    # Create a new JS Context. :with => self means that
    # the global namespace is the current context
    js = V8::Context.new(:with => self)
 
    # Load up our JS file
    js.load(File.join(Rails.root, 'public', 'javascripts', 'application.js'))
 
    # Define a mock method for getting JSON data
    def getJSON(url, callback)
      # When the JS wants some data, get it for real w/ capybara
      visit url
      # And call the JS function passed in (ruby => js)
      callback.call(page.body)
    end
 
    js.eval %{
      /* Mock out jQuery */
      var $ = {};
 
      /* Setup the mock in the right place (JS => ruby) */
      $.getJSON = getJSON; 
 
      /* Mock out jquery parseJSON to call ruby JSON.parse
         Since the args are the same, it is plug and play!
         (JS => ruby) */
      $.parseJSON = JSON.parse;
 
      /* Trigger our JS */
      getRemoteData();
 
      /* Assert what we expect (JS => ruby) */
      assert_equal(" ", dataObject.access_key);
    }
  end

This is not an example of an incredibly useful test, but I found the ability to bind back and forth easily between ruby and javascript to be mind-blowingly incredible. I mean, look at that last line, where I call assert and pass a javascript object to it!

Huge thanks to Charles Lowell (cowboyd) for his hard work on therubyracer.

Enjoy the weekend!

Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

Maintenance

• Fix various timezone-related issues. Notably, when traveling to a DateTime
  instance specified in a non-local timezone, convert provided DateTime
  instance to a local instance and return that from DateTime.now.
  Code contributed by Michaël Witrant [piglop]
• Fix bug that would not allow Timecop to be used when Ruby’s ‘date’
  library had not been previously loaded.
  Code contributed by Tuomas Kareinen [tuomas]
• Fix bug when traveling to a DateTime across a DST boundary that
  resulted in DateTime’s being off by an hour.
• Migrate argument parsing into Timecop::TimeStackItem to reduce the
  responsibility of the Timecop class.

Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.

Documentation is on RubyForge. The source code is hosted at GitHub.

Updates include:

API

• Completely remove Timecop#unset_all (deprecated by Timecop#return in 0.2.0)
• Return Time.now from #freeze, #travel and #return — code contributed by Keith Bennett (keithrbennett)

Maintenance

• Fix bug that left Time#mock_time set in some instances
• Upped build dependency to jeweler ~> 1.2.1
• Don’t pollute top-level namespace with classes/constants

Documentation

• Clearer examples in the README, better description in the gemspec
• Improve RDoc

I wanted to preview my HTML emails without having to fill up my online email inboxes with tons of email (and then I’d have to make filters too). I also didn’t want to manage actually sending real email. So, I set up my machine for local delivery. Read on for instructions.

I am running Ubuntu 9.04, however these instructions should be fine at least back to 8.04.

Step 1 – Install Postfix

sudo aptitude install postfix

During the install, choose “Local Delivery Only”

Step 2 – Configure Evolution for Receiving Locally

Open up Evolution “Applications->Internet->Evolution Mail”

Set up a new account and choose local delivery. When it asks you for a path, put in:

/var/mail/<username>

Note that this path may not exist if you’ve never received mail.

Step 3 – Configure Sanitize Email

In your rails test environment.rb put:

config.action_mailer.delivery_method = :sendmail

Then, in the initializer where you set up sanitize email:

ActionMailer::Base.sanitized_recipients = ["@"]
ActionMailer::Base.local_environments = %w( test )

If you need to know your username or hostname, just open up a terminal. The command “whoami” will give you your username, and “hostname” will give you the hostname.

Step 4 – Run your tests

Now, run your rails tests. You should have a test for every email you send, and that should trigger them to be sent locally. You may have to tell Evolution to Send/Receive. Keep in mind your tests will probably fail because they will expect email to be in test mode.

Step 5 – Set it back

Remember, when you’re done previewing your email, reset config.action_mailer.delivery_method!

So what about rails applications? Often, test data only contains a small amount of data. Over time more users use the site and generate more data. A page that usually renders in 100ms could be taking 3-5 seconds, or more!

I present, SlowActions. The goal was to analyze a standard log file to detect actions that render slowly. It had to be easy to use and also not require modification of rails’ logging mechanism. Observe:

  $> slow-actions --actions development.log
             Cost    Average Max
  - UsersController : game_history (22 entries, 0% Error)
    Total:   11275.447 3642.437 12728.0
    Render:  7.20300 2.32700 17.2450
    DB:      10.5020 3.39200 10.0000

  - QuestionsController : refresh_index_table (89 entries, 0% Error)
    Total:   908.494 202.348 307.000
    Render:  0.00000 0.00000 0.00000
    DB:      32.5880 7.25800 10.0000

More info after the break ….

So, what are we looking at? These are the top two (because I cut off the rest) results for looking at all the log entries times sorted by their Cost. The first line is the Controller followed by the Action. In parenthesis is the number of entries in the log file and the percent of those entries that had an error.

The second line is the total time from request to the data being sent to the user. There is a column for Cost, Avg, and Max. Max is the maximum time this action ever took. Avg is the average amount of time the action took (not counting errors). Cost = Avg * Math.Log(# entries).

The Cost can be thought of as that action’s share of the slowness of the site. An action that is only run once a month and takes 5 seconds is not as bad as an action run 200 times per day that takes 1 second. The Log helps smooth things out a bit.

There are a bunch of filters that you can put on the command:

$> slow-actions (--actions | --controllers | --sessions) log_file [log_file ...]
    You may also specify:
      --min-cost=FLOAT
      --min-avg=FLOAT
      --min-max=FLOAT
      --start-date=YYYY-MM-DD
      --end-date=YYYY-MM-DD

You can choose to output the actions and/or controllers (in a tree format) and/or the session ids (to see which users have it the worst, this is great to find out what is causing a slow action). You can also specify multiple log files, in case you rotate your logs.

You can choose a cutoff cost/avg/max, which means that you could make nice short little emails to yourself every night from your app.

You can also specify a date range, because after you fix a bug, you want to see what kind of effect it had.

I took care to put in some basic RDoc to help people use slow-actions in their own tests or tasks. For example, you could run this in irb:

require 'rubygems'
require 'slow_actions'
@sa = SlowActions.new
@sa.parse_file('/path/to/my/log')
puts @sa.print_actions

Have I convinced you? Then get SlowActions off GitHub and download it and run it on your app, you’ll be surprised!

As a Ruby programmer, I’ve come to love test-driven programming. As such, I’ve made an effort recently to build a test-based workflow into this existing codebase (not always the easiest thing to do, applying a test-base to a large existing codebase). Today I found myself in dire need of being able to test private functions in C++. As a testament to the poor state of testing in other programming languages, many message boards/threads simply told me that I was testing the wrong thing (you should test the public API, not the private implementation). Well, needless to say, this left me a bit uncomfortable. The fact is, the majority of my code is tucked into private methods, and I’d be left with huge long-running end-to-end tests if I strictly followed this heuristic.

However, I came across one golden nugget, one of the most clever hacks I’ve seen in some time. By utilizing pre-processor directives, we can temporarily override the meaning of private and protected in C++ code, essentially aliasing it to public.

 #define protected public
 #define private   public
 #include "TheClassHeaderUnderTest.h"
 #undef protected
 #undef private

See what this is doing? We wrap the class that we’ll be testing in pre-processor directives to interpret protected and private as an alias for public, essentially loading that class (when including the header file) as entirely public. This allows me to access everything! Private methods, private variables, you name it. And now, just like in Ruby, it’s no holds barred, allowing me to poke and prod my objects without being wrapped on the wrist by the compiler.

Even better, these directives simply wrap your includes in your test files. In other words, I don’t have to change my implementation to achieve this.

A clever hack, no matter the language or technology, is a clever hack. And I absolutely love this hack.

Credit: I discovered this technique as a comment on this wiki.

Expected response to be a <:redirect>, but was <500>
<"No HTTP_REFERER was set in the request to this action, so
redirect_to :back could not be called successfully. If this
is a test, make sure to specify
request.env[\"HTTP_REFERER\"].">

What a lovely error message to send me on a goose chase trying to set HTTP_REFERER directly on the @request as instructed.

Did Not Work

@request.env["HTTP_REFERER"] = '/'
post upload_path, { :file => fixture_file_upload("worddoc.docx", "application/msword") },
  { :html => {:multipart => true} }
assert_redirected_to '/', 'index'

This continued to spit out the same error. I finally stumbled across a post back from 2006 that held the answer. The HTTP_REFERER is not set the same way in an integration test:

Success!

post upload_path, { :file => fixture_file_upload("worddoc.docx", "application/msword") },
  { :html => {:multipart => true}, :referer => '/' }
assert_redirected_to '/', 'index'

Hope that saves anyone else some time if you encounter this error.

The primary feature added was the distinction between “freezing” and “rebasing” time. In 0.1.0, Timecop.travel would actually freeze time. This is no longer the case. Rather, a time offset will be calculated, and a running clock is simulated by always offsetting the time returned by Time.now (and friends) by the original offset.

(Note that time can still be frozen with Timecop.freeze.)

To update a previous version:

sudo gem update timecop

To install for the first time:

sudo gem install timecop

The new feature set allows us to avoid the following common pitfalls that were present in 0.1.0.

1. In rails, if you had set up a time mock in the development environment, then every time you invoked script/generate migration (and others), the generator would read your mocked instance of Time.now, and use that date for the migration name.
2. Any benchmarking/timing code executed within the yielded block would always return times of 0 seconds. This was due to time being frozen.

The other major change to the API was the deprecating of Timecop.unset_all in favor or Timecop.return.

This update also vastly improves the rdoc, making the public API much more accessible. The Timecop class has particularly thorough documentation.

For a more complete description of the gem, please refer to the introductory blog post.

This past weekend I released v0.1.0 of the Timecop gem. Timecop makes it dead simple to travel through or freeze time for the sake of creating a predictable and ultimately testable scenario.

The gem is derived from a plugin I wrote a while back to achieve more or less the same functionality for an extremely time-sensitive application. My goals for the gem included:

1. Drop-in-ability: The primary goal is to allow your app to continue to use Time.now, Date.today and DateTime.now as normal within your application. No overloading of functions with optional arguments (a la today=Date.today) just so you can write test cases.
2. Environment independence: I wanted the gem to work (a) w/ rails (ActiveSupport actually), (b) w/ plain ruby when the ‘date’ library has been loaded, and (c) w/ plain ruby when the ‘date’ library had not been loaded.
3. Library independence: I could have utilized mocha to achieve the mocking functionality found under the hood, but because I wanted this to work with plain vanilla ruby, libraries like mocha are out.
4. Short-term time travel: I wanted to expose the ability to temporarily change the concept of “now.” This is particularly helpful when writing tests where time needs to pass.
5. Long-range time travel: I wanted to expose the ability to change the concept of “now” for an indeterminate period of time. This is particularly helpful when setting up a rails test environment along with the test data.
6. Nested time travel: I wanted to provide the ability to nest traveling, allowing the state to be kept within each block (we’ll see an example later).

The gem is hosted on RubyForge and can be installed by simply running:

sudo gem install timecop

Using Timecop

The most basic example is to utilize this within a test. Consider the following test case:

require 'timecop'
require 'test/unit'
 
class MyTestCase < Test::Unit::TestCase
  def test_mortgage_due_in_30_days
    john = User.find(1)
    john.sign_mortgage!
    assert !john.mortgage_payment_due?
    Timecop.travel(Time.now + 30.days) do
      assert john.mortgage_payment_due?
    end
  end
end

What’s nice about this API is that the #travel function will take several different object types. You can pass a Time instance, a Date instance, a DateTime instance, or individual time parameters (the same arguments Time.local()) takes. Also, if you’re a big fan of the chronic gem, then you can easily combine these two:

Timecop.travel(Chronic.parse('this tuesday 5:00')) do
  # test-fu
end

For some applications, you may find it useful to completely re-base the concept of “now” for your test environment. Whenever time-sensitivity is a major priority for your application (e.g. an ordering and delivery system, or any system that encapsulates the concept of “availability” at a particularly fine-grained level) , you may find it useful to “root” your test data at a particular point in time, allowing you to write very specific tests that don’t fall victim to the unstoppable march of real time.

To achieve a static date for your entire test environment, you can simply drop the following into config/environments/test.rb (or config/test/environment.rb if you use environmentalist):

# Setting "now" to May 15, 2008 10:00:00 AM
Timecop.travel(Time.local(2008, 5, 15, 10, 0, 0))

This will cause your whole application to run at a static time. As mentioned previously, this is particularly important for creating static test cases. You may think that you can achieve this by always using relative times, but this proves much more difficult than initially perceived. For example, let’s consider the following scenario, which is an extension of the mortgage example beforehand. Let’s say the business rule is that a mortgage payment is due every month on the same date as the lease is signed, except for when that day falls on a weekend, in which case the payment would be due the following Monday. As such, it’s extremely crucial for us to write a test case where we know the date in the next month falls on a weekend, and a separate test case where the date in the next month falls on a weekday. As such, there are certain months where the following test (not using Timecop) would fail:

require 'test/unit'
 
class MyTestCase < Test::Unit::TestCase
  def test_mortgage_due_in_30_days
    john = User.find(1)
    john.sign_mortgage!
    assert !john.mortgage_payment_due?
    assert john.mortgage_payment_due?(Chronic.parse("1 month from now"))
  end
end

Furthermore, you’ll notice I had to pass a date to the mortgage_payment_due? function, essentially requiring me to change the signature of that function to take an optional date argument. Basically, in order to test my application, I’ve had to go ahead and change my actual code! Something clearly smells here. Another option would be to use mocha to mock Time.now. However, mocha has its own limitations with its inability to unmock. Lastly, specifically mocking Time.now would leave us high and dry if our implementation decided to start using DateTime.now for comparison in lieu of Time.now.

Another feature that I want to illustrate is the ability to nest #travel commands. The following assertions will all pass:

   # this test is taken directly from the test/test_timecop.rb
  def test_recursive_travel
    t = Time.local(2008, 10, 10, 10, 10, 10)
    Timecop.travel(2008, 10, 10, 10, 10, 10) do 
      assert_equal t, Time.now
      t2 = Time.local(2008, 9, 9, 9, 9, 9)
      Timecop.travel(2008, 9, 9, 9, 9, 9) do
        assert_equal t2, Time.now
      end
      assert_equal t, Time.now
    end
    assert_nil Time.send(:mock_time)
  end

Lastly, Timecop handles the scenario where exceptions are raised within the blocks passed to the #travel function.

  # this test is taken directly from the test/test_timecop.rb
  def test_exception_thrown_in_travel_block_properly_resets_time
    t = Time.local(2008, 10, 10, 10, 10, 10)
    begin
      Timecop.travel(t) do
        assert_equal t, Time.now
        raise "blah exception"
      end
    rescue
      assert_not_equal t, Time.now
      assert_nil Time.send(:mock_time)
    end
  end

Timecop is useful both in small and large consumption. Just as mocha can be helpful to give you a quick mock here and there, Timecop can help guide you very easily through testing the few time-sensitive parts of your application. And for those unique applications where everything is time-sensitive, Timecop gives you a very simple way to stabilize your concept of now.

Combining these tools together, we can do some pretty nifty code performance analysis in very few lines of code, e.g.

require 'rubygems'
require 'better-benchmark'
 
result = Benchmark.compare_realtime(:iterations => 10) { |iteration|
  save_the_world()
}.with { |iteration|
  save_the_world_and_save_the_girl()
}
Benchmark.report_on result

I have forked better-benchmark and wrapped the library up into a RubyGem.

Currently, the gem is available from github:

$> sudo gem install jtrupiano-better-benchmark

Based on preliminary discussions with Pistos, he intends to merge my changes back into his branch. I’ll update this post with the relevant details when that has been completed.

So, let’s get started by preparing your box for better-benchmark!

Installing R

On Mac OSX

This one’s simple. AT&T Research provides us with a DMG.

On Ubuntu 8.0.4

I first built this just fine on a Mac. But, I decided that I wanted a dedicated VM where I could run some fairly intense benchmarks. You’ll need to ensure you have the following apt packages installed:

* build-essential
* g77 (fortran compiler)
* x11-common

There may be a few others that are required, but I started on a pre-built box more or less ready to host rails apps, and so there may be a few other necessities I missed. The following steps will install R from source on Ubuntu (I was unable to get the necessary R headers installed using apt-get or apititude), and prepare you for installing the rsruby gem.

$> sudo apt-get install build-essential g77 x11-common
$> cd /opt
$> wget http://lib.stat.cmu.edu/R/CRAN/src/base/R-2/R-2.7.2.tar.gz
$> tar xzf R-2.7.2.tar.gz
$> cd R-2.7.2
# --enable-R-shlib is important...it signals the installer to build and make available libR.so
$> ./configure --enable-R-shlib
$> make
$> sudo make install

Installing rsruby

Assuming you installed R fine, rsruby should be easily installed using gem. If you have trouble, see the installation instructions on the project’s README.

Note that you’ll need to set the R_HOME environment variable prior to installing the gem. On Mac, R_HOME=/Library/Frameworks/R.framework/Resources. On Ubuntu (when installed from source), R_HOME=/usr/local/lib/R. I find it helpful to just drop this into /etc/environment (on Ubuntu) so that this variable is set upon login.

$> export R_HOME=/path/to/R/for/your/OS
$> sudo gem install rsruby -- --with-R-dir=$R_HOME

Installing better-benchmark

Currently, you can get this directly off of my fork on github.

$> gem sources -a http://gems.github.com/
$> sudo gem install jtrupiano-better-benchmark

Great, I have it, now what do I do with it??

So now we’re ready to benchmark something. The most important thing to understand when benchmarking is that you need to clearly identify what is part of the benchmark, and what is not. Let’s take a look at a real-world example. We’ll go through the following steps:

1. Hypothesize: define exactly what you’re looking to test, and take special care to describe what you are NOT testing.
2. Plan: write out step by step how you will accomplish your benchmark
3. Refine: identify which steps belong in the benchmark, and which are really setup/teardown aspects of the benchmark, and thus shouldn’t be included in the test.
4. Test: run the benchmarks
5. Rinse/Repeat: (as necessary) tweak your test parameters, tweak the tests, re-test

Real world example

I was building a set of services that needed to download tens to hundreds of thousands of feeds regularly and perform some post-processing. I pulled in the feed-normalizer gem. My implementation plan called for me to write separate services, one for “pulling down” the feed, and one for “processing” the feed.

My first approach entailed storing the feeds on the hard-drive as YAML (using the to_yaml function). After running into some obscure problems with YAML and multi-line strings, I started to explore alternative persistence formats. One that caught my attention was using the Marshall standard library to store the content as bytecode. This brings me to my hypothesis:

1) Hypothesis: Converting FeedNormalizer::Feed objects to bytecode using the Marshal library is faster than converting those same obejcts to YAML using the YAML library.

I also like to list out my goals at this stage:

1. We only want to test the #dump conversion (object –> string) and the #read conversion (string –> object). We do not want to test the write to disk and the read from disk portions.
2. We specifically want to test FeedNormalizer::Feed objects, since that’s what we’re using in our code.
3. Let’s benchmark YAML / Marshal #dump and #read methods specifically on FeedNormalizer::Feed objects

2) Plan:

1. We have already grabbed roughly 100 feed downloads, and they are sitting as raw xml in test/raw_rss.
2. We’ll read them in, then benchmark YAML.dump vs. Marshal.dump
3. Then we’ll independently benchmark YAML.read vs. Marshal.read

3) Refine:
Here’s where we need to ensure that unnecessary processing doesn’t make its way into our benchmarks. For instance, in order to benchmark Marshal#dump against YAML#dump, we’ll need to load up all of the FeedNormalizer::Feed objects (by reading them from disk and instantiating them) prior to starting the benchmark.

4) Test:
It’s a ruby script, so go ahead and run it. The set of options provided by better-benchmark are easily discernible from the source file.

5) Rinse/Repeat:
Same story as always.

Real Script Example

#!/usr/bin/env ruby
# Author: John Trupiano
# 2008-09-28
#
# In order to run this benchmark, you need to have the better-benchmark library installed (http://github.com/Pistos/better-benchmark/tree/master)
# better-benchmark depends on the rsruby gem (http://web.kuicr.kyoto-u.ac.jp/~alexg/rsruby/)
# rsruby depends on an installation of the computing package R (http://mirrors.ibiblio.org/pub/mirrors/CRAN/)
#
# For details on setting up R, rsruby, and better-benchmark, see this blog post: http://blog.smartlogicsolutions.com/2008/10/08/benchmark-ruby-code-with-r-rsruby-and-better-benchmark
 
# This is intended to be run from RAILS_ROOT, e.g.
# /path/to/rails/root $> ruby test/benchmark/yaml_bytecode_test.rb
 
require 'openssl'
require 'yaml'
require 'rubygems'
require 'feed-normalizer'
require 'lib/rss_parser'
require 'better-benchmark'
 
# GOALS 
# 1) We only want to test the #dump conversion (object --> string) and the #read conversion (string --> object).  We do not want to test the write to disk and the read from disk portions.
# 2) We specifically want to test FeedNormalizer::Feed objects, since that's what we're using in our code.
# 3) Let's benchmark YAML / Marshal #dump and #read methods specifically on FeedNormalizer objects
 
# PLAN
# 1) We've grabbed roughly 100 feed downloads sitting in test/raw_rss.
# 2) We'll read them in, then benchmark YAML.dump vs. Marshal.dump
# 3) Then we'll independently benchmark YAML.read vs. Marshal.read
 
fn_feeds = {}
root_dir = File.join("test", "raw_rss")
feed_ids = (1..62).to_a + (64..108).to_a
 
# build a global hash fn_feeds that contains the FeedNormalizer::Feed entries
feed_ids.each do |feed_id|
  infile = File.join(root_dir, feed_id.to_s, feed_id.to_s + '_dump.rss')
  fn_feeds[feed_id] = RssParser.parse(infile, :file)
end
 
#### BENCHMARK 1 ####
result = Benchmark.compare_realtime(
  :iterations => 25,
  :verbose => true
) { |iteration|
  fn_feeds.each_pair do |feed_id, feed|
    YAML.dump(feed)
  end
}.with { |iteration|
  fn_feeds.each_pair do |feed_id, feed|
    Marshal.dump(feed)
  end
}
Benchmark.report_on result
 
 
# now, let's create separate collections storing the dumps
yaml_dumps = {}
marshal_dumps = {}
fn_feeds.each_pair do |feed_id, feed|
  yaml_dumps[feed_id] = YAML.dump(feed)
  marshal_dumps[feed_id] = Marshal.dump(feed)
end
 
#### BENCHMARK 2 ####
result = Benchmark.compare_realtime(
  :iterations => 25,
  :verbose => true
) { |iteration|
  yaml_dumps.each_pair do |feed_id, yaml|
    YAML.dump(yaml)
  end
}.with { |iteration|
  marshal_dumps.each_pair do |feed_id, marshal|
    Marshal.dump(marshal)
  end
}
Benchmark.report_on result

And for good measure, let’s take a look at the results.

john-trupianos-macbook-pro:trunk john$ ruby test/benchmark/yaml_bytecode_test.rb
.........................
Set 1 mean: 2.095 s
Set 1 std dev: 0.071
Set 2 mean: 0.123 s
Set 2 std dev: 0.019
p.value: 1.58214572048972e-14
W: 625.0
The difference (-94.1%) IS statistically significant.
.........................
Set 1 mean: 0.191 s
Set 1 std dev: 0.015
Set 2 mean: 0.022 s
Set 2 std dev: 0.012
p.value: 1.58214572048972e-14
W: 625.0

As R plainly tells us, the difference is statistically significant (those who remember their p-values from stats class raise your hands) for both benchmarks (note that I did run two separate benchmarks in this example, one for dumping and one for reading). That said, considering I don’t have a need for this data to be human readable on my filesystem, I can safely conclude that using the Marshal library in lieu of the YAML library will give me a performance boost on both the read/dump methods. Now, whether or not this boost is negligible in the scope of the greater system, well that’s a question for a separate benchmark.

(What I mean by this last part is that this #dump/#read portion of my whole system may be tiny. If it only represents 0.5% of the processing time, then the improvement my example shows may be more or less negligible in the context of the whole system. These are the types of questions you need to ask yourself when benchmarking.)

Primary take-home point: know what you’re benchmarking, and benchmark what you don’t know.