maria-developers team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

On Fri, Sep 23, 2011 at 4:32 AM, Kristian Nielsen
<knielsen@xxxxxxxxxxxxxxx> wrote:
> MARK CALLAGHAN <mdcallag@xxxxxxxxx> 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@xxxxxxxxx