On Fri, Sep 23, 2011 at 4:32 AM, Kristian Nielsen <kniel...@knielsen-hq.org> wrote: > MARK CALLAGHAN <mdcal...@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 mdcal...@gmail.com _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
