EM runs really quite well as it is. A couple of speedups might be possible: 1) in the C code use an array instead of a heap for looking up the UID''s of the sockets. i.e. fd xx -> slot xx in an array. 2) make a direct Ruby call on those objects. I.e. instead of cacheing UID''s, cache the ruby objects, themselves, then just call "receive_data" directly on that object. But anyway keep up the good work! -=r
On 19 Jan 2009, at 22:38, Roger Pack wrote:> EM runs really quite well as it is. > A couple of speedups might be possible: > 1) in the C code use an array instead of a heap for looking up the > UID''s of the sockets. i.e. fd xx -> slot xx in an array.Interesting, yes, that could make a difference.> 2) make a direct Ruby call on those objects. I.e. instead of cacheing > UID''s, cache the ruby objects, themselves, then just call > "receive_data" directly on that object.This could make a huge difference, but it will also widen the API for integration with ruby. I''m actually going for a more OO approach (and drop the C++ standalone support) in a fork I recently started, but I need to be careful not to push too much back up into ruby. One of the main advantages EM has is the fact that it avoids the ruby implementations of various core features (sockets, timers, error handling, etc). It''s also interesting to note that the OO stuff being the major difference in Rev seems to have had a stern effect on performance there. That being said, I haven''t had a good look at Revs underlying (integration) approach or profiled it to see if it can be made much faster with any ease.> But anyway keep up the good work! > -=r > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk
>> 2) make a direct Ruby call on those objects. I.e. instead of cacheing >> UID''s, cache the ruby objects, themselves, then just call >> "receive_data" directly on that object. > > This could make a huge difference, but it will also widen the API for > integration with ruby. I''m actually going for a more OO approach (and drop > the C++ standalone support) in a fork I recently started, but I need to be > careful not to push too much back up into ruby. One of the main advantages > EM has is the fact that it avoids the ruby implementations of various core > features (sockets, timers, error handling, etc). It''s also interesting to > note that the OO stuff being the major difference in Rev seems to have had a > stern effect on performance there. That being said, I haven''t had a good > look at Revs underlying (integration) approach or profiled it to see if it > can be made much faster with any ease.Yeah it would force more of an integration with ruby is the drawback. It is indeed fascinating how much slower rev is than EM [is it just because rev does most of its work in pure ruby?]. AFAIK rev would basically need a rewrite to move the speed sensitive parts into C, then it would probably be as fast as EM. We can hope :) -=r
On Tue, Jan 20, 2009 at 11:25 AM, Roger Pack <rogerpack2005 at gmail.com>wrote:> It is indeed fascinating how much slower rev is than EM [is it just > because rev does most of its work in pure ruby?]. > > AFAIK rev would basically need a rewrite to move the speed sensitive > parts into C, then it would probably be as fast as EM. We can hope :) >It''s been awhile since I benchmarked Rev to figure out where the slowness actually was. I believe there''s a death by a thousand paper cuts thing going on regarding how many Ruby method calls it actually takes to dispatch out of the reactor core in C. Moving to a proactor core in C would get rid of a number of the calls. As for how much that would speed it up, only benchmarks would tell. -- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/eventmachine-talk/attachments/20090120/44392c1b/attachment.html>
What is Rev? On Tue, Jan 20, 2009 at 1:41 PM, Tony Arcieri <tony at medioh.com> wrote:> On Tue, Jan 20, 2009 at 11:25 AM, Roger Pack <rogerpack2005 at gmail.com> > wrote: >> >> It is indeed fascinating how much slower rev is than EM [is it just >> because rev does most of its work in pure ruby?]. >> >> AFAIK rev would basically need a rewrite to move the speed sensitive >> parts into C, then it would probably be as fast as EM. We can hope :) > > It''s been awhile since I benchmarked Rev to figure out where the slowness > actually was. I believe there''s a death by a thousand paper cuts thing > going on regarding how many Ruby method calls it actually takes to dispatch > out of the reactor core in C. > > Moving to a proactor core in C would get rid of a number of the calls. As > for how much that would speed it up, only benchmarks would tell. > > -- > Tony Arcieri > medioh.com > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >
Another event library for Ruby (one I wrote), based on libev: http://rev.rubyforge.org/ On Wed, Jan 21, 2009 at 12:21 PM, Daniel Aquino <mr.danielaquino at gmail.com>wrote:> What is Rev? > > On Tue, Jan 20, 2009 at 1:41 PM, Tony Arcieri <tony at medioh.com> wrote: > > On Tue, Jan 20, 2009 at 11:25 AM, Roger Pack <rogerpack2005 at gmail.com> > > wrote: > >> > >> It is indeed fascinating how much slower rev is than EM [is it just > >> because rev does most of its work in pure ruby?]. > >> > >> AFAIK rev would basically need a rewrite to move the speed sensitive > >> parts into C, then it would probably be as fast as EM. We can hope :) > > > > It''s been awhile since I benchmarked Rev to figure out where the slowness > > actually was. I believe there''s a death by a thousand paper cuts thing > > going on regarding how many Ruby method calls it actually takes to > dispatch > > out of the reactor core in C. > > > > Moving to a proactor core in C would get rid of a number of the calls. > As > > for how much that would speed it up, only benchmarks would tell. > > > > -- > > Tony Arcieri > > medioh.com > > > > _______________________________________________ > > Eventmachine-talk mailing list > > Eventmachine-talk at rubyforge.org > > http://rubyforge.org/mailman/listinfo/eventmachine-talk > > > _______________________________________________ > Eventmachine-talk mailing list > Eventmachine-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/eventmachine-talk >-- Tony Arcieri medioh.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/eventmachine-talk/attachments/20090121/950f3522/attachment.html>
Another "extreme" way that might squeeze performance out of it would be to use the CPU clock counter and CLOCKS_PER_SEC to calculate elapsed time, instead of systemtimer or whatever EM currently uses. Not sure how much of a hit that is, though, really. [ruby prof has some code that does it, I believe]. Take care. -=r