wxruby development - May 2008 - [ wxruby-Patches-20130 ] Event handling performance issues

Patches item #20130, was opened at 2008-05-14 01:26
You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=220&aid=20130&group_id=35

Category: None
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Cezar Espinola (cezarsa)
Assigned to: Nobody (None)
Summary: Event handling performance issues

Initial Comment:
Hi folks.

This little patch intend to increase the performance on event handling. Based on
my tests I could get a 40% increase in the number of events generated per
second.

A little background history:
As I had previously worked with wxPython, I thought that sometimes wxRuby was
not responding as fast as it did in wxPython, specially on events that keep
being generated like EVT_MOTION and EVT_IDLE.
As a proof of that I wrote a small benchmark script (ruby version attached)
using both wxPython and wxRuby. It was not my surprise that on my machine I had
wxPython with an average of 97033 events/second and wxRuby with 39435
events/second. The script does not intend to have scientific rigor but it
demonstrates what I meant.

The patch modifies mainly the behavior of wxRuby_WrapWxEventInRuby(). One of the
great bottlenecks that I could find was the C++ code calling
Wx::EvtHandler.event_class_for_type() on the ruby side every time a new event is
generated. I modified it to directly access the
Wx::EvtHandler::EVENT_TYPE_CLASS_MAP hash (and saving it in a global variable
after the first lookup), leading to a great performance improvement.
Another minor change was in wxRbCallback::EventThunker, just to avoid repeated
calls to rb_intern.

After these changes my benchmark script reported an average of 55264
events/second! About 40% increase upon the first mark, quite impressive
performance boost with simple changes. :)

I''m still looking for a way to reach the ''python
level'', but I think most part of the problem is related to VM issues.

----------------------------------------------------------------------

You can respond by visiting: 
http://rubyforge.org/tracker/?func=detail&atid=220&aid=20130&group_id=35