On 28/06/2012, at 12:13, Ben Noordhuis wrote: > On Thu, Jun 28, 2012 at 10:40 AM, Jorge <jo...@jorgechamorro.com> wrote: >> >> >> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L202 >> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L281 >> https://github.com/xk/node-threads-a-gogo/blob/master/src/threads_a_gogo.cc#L646 >> https://github.com/xk/node-sound/blob/master/src/sound.cc#L509 >> https://github.com/xk/node-sound/blob/master/src/sound.cc#L1014 >> >> But ev_async_pending is a macro that expands to this: >> >> if (!(+(&watcher)->sent)) ev_async_send(ev_default_loop_uc_ (), &watcher); >> >> which is not a function call, soooo.... it's not a good idea to make it "the >> default behaviour", because if you do that the check would be made inside >> uv_async_send() so the function call would happen always which is exactly >> what one's trying to avoid when using ev_async_pending. > > I'm not that worried about the function call overhead. The reason that > you're seeing a slowdown is that uv_async_send() is always making a > syscall now.
Yes, libuv is handling my async events (370-230)/(370/100) = 38% slower than libev. The difference -in my Mac- between making the watcher.sent test before the ev_async_send() call and making it after/inside the ev_async_send() call is of about a 30% in performance loss in that single line of code alone: <https://gist.github.com/3011746> $ gcc -O0 /Users/jorge/Desktop/functionCall.c $ ./a.out without a function call: 2.779617 ns per iteration with a function call : 3.572935 ns per iteration With the function call it's 28.540551 percent slower than without the function call In the grand total this may not matter much, but in low level code such as this every ns counts imo. -- Jorge.
