We talked a bit about improving the performance encode/decode
yesterday at CDS:
http://pad.ceph.com/p/hammer-buffer_encoding
I think the main takeaways were:
1- We need some up to date profiling information to see
- how much of it is buffer-related functions (e.g., append)
- which data types are slowest or most frequently encoded (or otherwise
show up in the profile)
2- For now we should probably focus on the efficiency of the encode/decode
paths. Possibilities include
- making more things inline
- improving the past path
3- Matt and the linuxbox folks have been playing with some general
optimizations for the buffer::list class. These include combining
some of the function of ptr and raw so that, for the common
single-reference case, we chain the raw pointers together directly from
list using the boost intrusive list type, and fall back to the current
list -> ptr -> raw strategy when there are additional refs.
For #2, one simple thought would be to cache a pointer and remaining bytes
or end pointer into the append_buffer directly in list so that we avoid
the duplicate asserts and size checks in the common append (encode) path.
Then a
::encode(myu64, bl);
would inline into something pretty quick, like
remaining -= 8;
if (remainining < 0) { // take slow path
} else {
*ptr = myu64;
ptr += 8;
}
Not sure if an end pointer would let us cut out the 2 arithmetic ops or
not. Or if it even matters on modern pipelining processors.
Anyway, any gains we make here will pay dividends across the entire
code base. And any profiling people want to do will help guide
things...
Thanks!
sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
