Hitimes are upon us

Saturday afternoon at the Lone Star Ruby Conf I was discussing something, I forget exactly what, with Bruce and he mentioned that he was looking for a really fast way to measure elapsed time of a piece of code.

The naive approach would be call Time.now before and after the call, or maybe use the Time.elapse method from Facets. Both of those approaches are perfectly acceptable, and return results down to the µsecond. Can we do better? Yes.

We have a goal of being faster than 2 successive Time.now calls. Each operating system has a different way accessing a high-resolution timer.

  • Unixes - the POSIX calls to clock_gettime()
  • OS X - UpTime()
  • Windows - QueryPerformanceCounter()

Unify the C level interface to all of those, wrap it up in a Ruby extension and the result is the just-released Hitimes, a high-resolution timer library in Ruby for when you want to do measuring at the nanosecond level.

gem install hitimes

The simplest and lightest weight way to use the library is via the Interval class. This does one really simple thing. It measures an interval of time. You can measure code in a block:

require 'hitimes'
require 'open-uri'
duration = Hitimes::Interval.measure do
            bruce = open("http://www.codefluency.com/").read
puts duration # => 0.261841618

Or measure a particular piece of code for performance:

interval = Hitimes::Interval.new
# do something
# some code to measure
duration = interval.stop

There are other approaches using Interval, and a Timer class for measuring series of intervals and reporting statistics.

Comments (View)

Post Lone Star Talk Thoughts

Fernand and I presented a talk at Lone Star Ruby Conf last Friday entitled Building and Managing a Ruby Infrastructure. It appears we hit upon a subject that people are starting encounter. Over the next couple of weeks I'll post a few more articles explaining in more detail a few of the key concepts. For now, a few links to things that we mentioned in the talk.

  • Bones -- A great project templating tool, extendible to use your own proect templates.
  • Rational Versioning Policy -- in which ~> a.k.a "Twiddle Wakka" is explained.
  • Stickler -- organize and maintain an internal gem distribution server. Still in planning stages.
  • take a look at the gem index and gem server commands

Comments (View)

Amalgalite Pthread Error

If you happen to get an error like the following when running amalgalite, it was a bug in how amalgalite was built. I wasn't matching the thread support in amalgalite with the threadsupport of the installed ruby.

amalgalite-0.2.0/ext/amalgalite3.so: undefined symbol: pthread_mutexattr_init

For future reference this is how you can see how ruby was compiled on my iMac

1.8.6 114 (2008-03-03) i686-darwin9.2.2
>> require 'rbconfig'
>> puts Config::CONFIG['configure_args']
 '--prefix=/opt/local' '--enable-shared' '--mandir=/opt/local/share/man'
 '--enable-pthread' '--without-tk' 'CC=/usr/bin/gcc-4.0' 'CFLAGS=-O2'
 'LDFLAGS=-L/opt/local/lib' 'CPPFLAGS=-I/opt/local/include'

versus my OpenBSD server:

1.8.6 110 (2007-09-23) x86_64-openbsd4.2
>> require 'rbconfig'
>>puts Config::CONFIG['configure_args']
 '--enable-shared' '--enable-ipv6' '--with-dbm-type=bogus'
 '--with-opt-dir=/usr/local' '--with-tcl-include=/usr/local/include/tcl8.4'
 '--with-tk-include=/usr/local/include/tk8.4' '--with-X11-dir=/usr/X11R6'
 '--prefix=/usr/local' '--sysconfdir=/etc' '--mandir=/usr/local/man'
 '--infodir=/usr/local/info' 'CC=cc' 'CFLAGS=-O2 -pipe'

You can see that on my iMac ruby was compiled with @--enable-pthread@ but on my OpenBSD machine that configuration option is missing. I didn't take this into account when building Amalgalite.

Version 0.2.1 was just released which fixes this bug.

gem install amalgalite

Comments (View)

Prev Next