include/encoding: do not try to be clever with list encoding

[liewegas]

I'm skeptical that this is faster, since the copy_in call needs to
figure out where to place the length value.

Signed-off-by: Sage Weil sage@redhat.com

[yuyuyu101]

I'm not sure the performance effect about this PR, I guess you may pay attention to bufferlist and encode/decode performance part.

I have two ideas for this topic:

1. avoid decode memcpy: the performance problem of decode isn't we need to copy a lot of bytes, but is we need call memcpy too many times. Llike map<string, bufferlist> or vector<string/bufferlist> structure, we need to call copy ops at least 2*element number. So for Message receive, I think we may could build a readonly map/vector alike structure, this structure just is owns some pointers to reference the raw message data buffer, we only need to keep message ref. Because for normal osd ops, we won't change map/vector from message data. So we could replace actual vector/map to a simple reference structure.
2. implement a lightweight bufferlist. I think we could provide with a lightweight bufferlist which use uint64_t as ref type instead of atomic. Because for most certain cases, we could keep lightweight bufferlist internal module use. For good design module, we only need to use a little shared bufferlist(current impl). This change also can help to avoid potential bufferlist abuse problem. From my last perf, each rados op will cause at least 200 atomic inc and 200 dec(only from bufferlist). We may not get the detail performance effect for the atomic ops, but I think the bus lock shouldn't be free enough to ignore.

[liewegas]

Rebased, updated comment.