On 1 nov. 08, at 12:16, Charles Oliver Nutter wrote:

> He doesn't have specific numbers for performance at the moment, but  
> the short story is that FFI introduces a bit of overhead; ultimately  
> I believe that the overhead gets lost in the flow of a Ruby  
> application, especially when you're tossing units of work across  
> like SQL queries or arrays.

# --- [begin unscientific test] --------

require 'rubygems'
require 'benchmark'
require 'zlib'
require 'ffi'
require 'dl/import'

module Zlib_ffi
     extend FFI::Library
     attach_function :zlib_version, :zlibVersion, [], :string
end

module Zlib_dl
     extend DL::Importable
     dlload "libz.dylib"
     extern "const char* zlibVersion()"
end

puts Zlib.zlib_version
puts Zlib_ffi.zlib_version
puts Zlib_dl.zlibVersion

Benchmark.bm(3) do |bm|
     bm.report("ext") { 500_000.times { Zlib.zlib_version } }
     bm.report("ffi") { 500_000.times { Zlib_ffi.zlib_version } }
     bm.report("dl")  { 500_000.times { Zlib_dl.zlibVersion } }
end

# --- [end unscientific test] --------

This gives the following results:

1.2.3
1.2.3
1.2.3
          user     system      total        real
ext  1.050000   0.320000   1.370000 (  1.373800)
ffi  2.160000   0.660000   2.820000 (  2.818966)
dl   3.500000   1.060000   4.560000 (  4.552789)

All this using MacPorts MRI 1.8.7-p72 under OS X 10.5.5. The observed  
overhead is slightly over 2x for ffi, probably not a big deal unless  
ffi calls are used in tight loops I guess.


PS: haven't seen any trace of variadic function support in the code.

-- 
Luc Heinrich - luc / honk-honk.com