On Fri, Sep 23, 2011 at 4:32 AM, Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
MARK CALLAGHAN <mdcallag@gmail.com> writes:
As also discussed in the RethinkDB blogs, one needs to be aware of performance, as some co-routine implementations (eg. POSIX ucontext) are inefficient. The use of co-routines in non-blocking libmysqlclient is particularly simple, so I added simple optimised implementation for i386 and x86_64, and benchmarked them.
Micro-benchmark on x86_64 shows that the cost of spawning a co-routine (compared to a direct function call) is about 12 cycles (64-bit Intel Sandy Bridge CPU). That is quite low. It's about the same cost as a pipeline stall (eg. a single mispredicted branch). I think one would be hard pressed to achieve such low overhead from the state machine/message passing needed for event-driven style (1).
I also benchmarked real library usage: fetch 100,000,000 rows using mysql_use_result()+mysql_fetch_row(). Rows have a single constant integer value pulled from a self join of MEMORY tables:
getcontext is slow because it saves everything --FP regs, SSE regs, signal handlers. It was safe for RethinkDB to skip saving them but they are not providing a library that can run in a wide variety of contexts. Why is it safe to skip them in this patch? -- Mark Callaghan mdcallag@gmail.com