Ruby extensions question..

[Aaron Smith]

So I'm getting slightly confused with writing ruby extensions and what
is best for performance.

I'm working on writing an extension for Ruby, but almost everything i'm
doing at the C level is with rb_* functions using the Ruby C API. I
understand how it works but isn't that just as slow as using Ruby? Or
no?

thanks

 

[james.d.masters]

So I'm getting slightly confused with writing ruby extensions and what
is best for performance.

I'm working on writing an extension for Ruby, but almost everything i'm
doing at the C level is with rb_* functions using the Ruby C API. I
understand how it works but isn't that just as slow as using Ruby? Or
no?

thanks

The performance improvement is not found in the Ruby interface to C
but rather in what is going on in the C code itself.

Example:

I write C code that does something computationally intensive - say it
takes about 1 hour to run. If I were to write a Ruby equivalent (only
in Ruby) then let's say that it takes 2 hours. But if I extend that C
code using the Ruby C API then my performance would be 1 hour plus
interface (rb_*) overhead - maybe on the order of a few seconds or
perhaps minutes.

 

[Aaron Smith]

The performance improvement is not found in the Ruby interface to C
but rather in what is going on in the C code itself.

Example:

I write C code that does something computationally intensive - say it
takes about 1 hour to run. If I were to write a Ruby equivalent (only
in Ruby) then let's say that it takes 2 hours. But if I extend that C
code using the Ruby C API then my performance would be 1 hour plus
interface (rb_*) overhead - maybe on the order of a few seconds or
perhaps minutes.

Thanks that helps.

One more question. Maybe this will end up having the same answer.. But
let's say I have an object that I pass to the ruby extension. and all
operations in the C code i'm doing are on that object passed using
rb_funcall, rb_iv_get, etc. is it still seeing performance gains with C?

thanks

 

[MenTaLguY]

One more question. Maybe this will end up having the same answer.. But
let's say I have an object that I pass to the ruby extension. and all
operations in the C code i'm doing are on that object passed using
rb_funcall, rb_iv_get, etc. is it still seeing performance gains with C?

Usually not much. Local variables are a little cheaper, and there's no AST-walking for evaluation, but that's about the extent of it. Ruby method calls are a lot more expensive, so the big wins are when you can avoid Ruby method calls (i.e. rb_funcall) altogether. Otherwise, it's just not worth the maintainability and portability problems.

-mental

 

[Aaron Smith]

Usually not much. Local variables are a little cheaper, and there's no
AST-walking for evaluation, but that's about the extent of it. Ruby
method calls are a lot more expensive, so the big wins are when you can
avoid Ruby method calls (i.e. rb_funcall) altogether. Otherwise, it's
just not worth the maintainability and portability problems.

-mental

Thanks, helps more. I think where I'm going with this is that its best
to write a C program that does everything needed. Then come back and
extend Ruby with those pieces. Instead of worrying about Ruby
integration now, wait till the straight C functionality is there.. Then
there should only be slight overhead of a few rb_* calls.

 

[MenTaLguY]

Thanks, helps more. I think where I'm going with this is that its best
to write a C program that does everything needed. Then come back and
extend Ruby with those pieces. Instead of worrying about Ruby
integration now, wait till the straight C functionality is there.. Then
there should only be slight overhead of a few rb_* calls.

I'd actually say it's the other way around -- write the program in Ruby, then
profile it to see where the slow spots are. Optimize those, and when
you've run out of things to optimize in Ruby, _then_ see if you can cut down
on method calls in critical places by pushing things into C. _if you need
to_ (you may not)

Trying to optimize too early just makes life harder for you, and there are a
surprising number of gotchas when embedding Ruby in a C program (rather than
vice-versa); the Ruby interpreter is not the most embedding-friendly.

-mental

 

[Aaron Smith]

I'd actually say it's the other way around -- write the program in Ruby,
then
profile it to see where the slow spots are. Optimize those, and when
you've run out of things to optimize in Ruby, _then_ see if you can cut
down
on method calls in critical places by pushing things into C. _if you
need
to_ (you may not)

Trying to optimize too early just makes life harder for you, and there
are a
surprising number of gotchas when embedding Ruby in a C program (rather
than
vice-versa); the Ruby interpreter is not the most embedding-friendly.

-mental

Thanks, Yes I have the ruby application RubyAMF already done. But I'm
trying to optimize the AMF de/serialization and figured C would be the
best solution. So now I just need write the C instead of worrying about
Ruby/AMF integration.. Once the C is working, tie that back into
Ruby/AMF.

 

[MenTaLguY]

Thanks, Yes I have the ruby application RubyAMF already done. But I'm
trying to optimize the AMF de/serialization and figured C would be the
best solution. So now I just need write the C instead of worrying about
Ruby/AMF integration.. Once the C is working, tie that back into
Ruby/AMF.

Ah, {de,}serialization code is one of those places where C is more often helpful.

That said, have you done profiling and taken advantage of all of the
pure Ruby optimization opportunities you've had first?

Performance bottlenecks can happen in very unexpected places, and heavily optimizing
one part of the code won't help you much if 90% of the execution time is happening
in a different part.

Another question to consider is if you are interested in supporting other Ruby
implementations (e.g. JRuby or Ruby.NET). If so, then it's best to minimize the
amount of code you push into C.

Along those lines, profiling may highlight one or two specific methods that need
to be done in C, versus rewriting a large part of the application.

-mental

 

[Aaron Smith]

Ah, {de,}serialization code is one of those places where C is more often
helpful.

That said, have you done profiling and taken advantage of all of the
pure Ruby optimization opportunities you've had first?

Performance bottlenecks can happen in very unexpected places, and
heavily optimizing
one part of the code won't help you much if 90% of the execution time is
happening
in a different part.

Another question to consider is if you are interested in supporting
other Ruby
implementations (e.g. JRuby or Ruby.NET). If so, then it's best to
minimize the
amount of code you push into C.

Along those lines, profiling may highlight one or two specific methods
that need
to be done in C, versus rewriting a large part of the application.

-mental

Hm. I haven't thought about JRuby or Ruby.NET. Don't know if it's
something I should worry about. I've done some profiling and overall the
application is pretty well tuned. The times when the application
performs slowly is when returning thousands of records from mysql. When
it's in the serializing code.

Here are a couple ruby-prof call graphs that illustrate the timeliness
of mysql VS returning a string

returning 3000 mysql records:
http://blog.rubyamf.org/profiling/serialize/mysql_3000_flat.txt
http://blog.rubyamf.org/profiling/serialize/mysql_3000_graph.txt

returning 1 string:
http://blog.rubyamf.org/profiling/serialize/string_flat.txt
http://blog.rubyamf.org/profiling/serialize/string_graph.txt

returning some number
http://blog.rubyamf.org/profiling/serialize/bignum_flat.txt
http://blog.rubyamf.org/profiling/serialize/fixnum_flat.txt
http://blog.rubyamf.org/profiling/serialize/float_flat.txt

You can start to see processing times increase in the mysql one at the
end of flat version.. Take a look, let me know what you think. I think
the performance gains would definitely be seen writing the
de/serializers with C..

Thanks for talking shop.
-Aaron

 

[Aaron Smith]

oh, if you haven't seen ruby-prof or call graphs.. you can google "ruby
call graphs".. here is a good tutorial as well..
http://ruby-prof.rubyforge.org/graph.txt
-Aaron

 

[MenTaLguY]

--=-o3XOUanuhvgo8jhhnOt+
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Here are a couple ruby-prof call graphs that illustrate the timeliness=20
of mysql VS returning a string

Yeah, it does indeed look like the serializer is a good candidate for a
C rewrite, which should remove the need for a lot of method calls.

I was also concerned about RUBYAMF::Util::BinaryString, given its heavy
use of delegation (which is quite expensive in principle), except
looking at the profile it doesn't seem to contribute to the times
anywhere near as much.

Keep up the good work,

-mental

--=-o3XOUanuhvgo8jhhnOt+
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGe1OVSuZBmZzm14ERAkzbAKCHqPcEswnPDujmMWUGnBT7tdOUaACgqQpQ
rFZkh72JjfKYHw8+OoO85nw=
=rOfP
-----END PGP SIGNATURE-----

--=-o3XOUanuhvgo8jhhnOt+--

 

[Aaron Smith]

Yeah, it does indeed look like the serializer is a good candidate for a
C rewrite, which should remove the need for a lot of method calls.

I was also concerned about RUBYAMF::Util::BinaryString, given its heavy
use of delegation (which is quite expensive in principle), except
looking at the profile it doesn't seem to contribute to the times
anywhere near as much.

Keep up the good work,

-mental

I've been looking through these profiles a bit more. Look at this line:
33.45 11.50 11.31 11.31 0.00 5159152 0.00 0.00
String#==
(a little more than half way down the page).

After looking over it more and more, the de/serialization times don't
seem that bad, there is a ton of time being spent in the String#==
though.

5 million calls? that's nuts. I'm wondering if part of all those calls
is from ruby-prof itself. If not, It's strange to me that the == is
being called so much. hmm. String#== has the most calls out of any
method call in the profile.

Do you think the de/serialization times could be noticeably improved?
Compared to trying to figure out why the String#== is called so much?

Any thoughts?

 

[Aaron Smith]

I've been looking through these profiles a bit more. Look at this line:

33.45 11.50 11.31 11.31 0.00 5159152 0.00 0.00
String#==
(a little more than half way down the page).

oh sorry. that String#== line is in the mysql_3000_flat.txt profile

 

[MenTaLguY]

Do you think the de/serialization times could be noticeably improved?
Compared to trying to figure out why the String#== is called so much?

I didn't have much time to look at the profile carefully last night, but the
impression I got was that a lot of the string comparison that was happening
was coming from WEBrick.

(I would be curious how much difference using Mongrel versus using WEBrick makes.)

-mental

 

[Aaron Smith]

I didn't have much time to look at the profile carefully last night, but
the
impression I got was that a lot of the string comparison that was
happening
was coming from WEBrick.

(I would be curious how much difference using Mongrel versus using
WEBrick makes.)

-mental

Interesting, I'll get that set up and test some more. I've also got
LightTPD working, I'll do some profiling with that as well.

Thanks

 

[Aaron Smith]

Interesting, I'll get that set up and test some more. I've also got
LightTPD working, I'll do some profiling with that as well.

Thanks

Hey mental,

Here is a Mongrel code profile of that same mysql cal that returns 3000
records..
http://blog.rubyamf.org/profiling/mongrel_mysql3000_graph.txt

the String#== method is still called 5 million times. Thats strange.
I've been trying to figure out where its coming from but can't quite pin
point it. I'll be poking around some more.. Anymore thoughts?

Also, what do you think about all the delegation that is happening to
the BinaryString Mixins? Seems like it's not a huge performance hit but
generally there are 3-4 method calls before any actual BinaryStirng
operation is happening (such as writing the packed bytes onto the
string).. I know someone had mentioned that method calls in Ruby are
taxing. Any thoughts?

Thanks man
Aaron