On 28/06/2012, at 16:50, Jorge wrote: > 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.
So, to recap, in my opinion it would be better to expose a public .sent in uv_async_t objects, or define a macro to replace ev_async_pending, say, uv_async_pending. WDYT? -- Jorge.