Use the Connection Buffer for Writing #134
Conversation
Try to remove unnecessary indirections and initialisations with zero. Also update links to the MySQL doc
| // shortcut which can be used if the requested buffer is guaranteed to be | ||
| // smaller than defaultBufSize | ||
| // Only one buffer (total) can be used at a time. | ||
| func (b *buffer) takeSmallBuffer(length int) []byte { |
There was a problem hiding this comment.
Everywhere this is used in packets.go, it's immediately followed by if data == nil based error handling, so even if it's inlined by the compiler, it always branches twice. b.length != 0 is the only way this can return nil, so I say manually inline all occurrences (and add a comment), use the buffer directly and drop the superflouus if for all 4 occurences.
That's bad from a code style perspective, but the comment should suffice. It will probably be a little faster and not more complex than it is now.
There was a problem hiding this comment.
Branches are not generally evil. In this case 1 branch miss is to be expected. I think keeping the buffer logic separate is worth it.
| @@ -621,13 +643,16 @@ func (rows *mysqlRows) readRow(dest []driver.Value) (err error) { | |||
| pos += n | |||
| if err == nil { | |||
| if !isNull { | |||
| if !rows.mc.parseTime { | |||
| if !mc.parseTime { | |||
| continue | |||
| } else { | |||
There was a problem hiding this comment.
drop else, deindent (though it's not originally part of this PR)
|
Done so far (oof), eager to TAL 😀 |
|
Independent of |
Use the Connection Buffer for Writing
Instead of allocating multiple small new slices and copy them in one big slice before sending (current approach) or the 2-Pass approach (Pass 1: getting the total size; Pass 2: packing in a new allocated slice with perfect size) in #71, this PR introduces yet another approach:
The connection buffer (currently only used for reading) is used for packing until the the buffer gets too small. At this point we (the builtin func append) start allocating bigger slices. This happens only for very large Queries since the buffer is by default 4KB large and can grow.
When the packing is finished, we can get the total size and write the packet header.
As a result, most packets can be built without making a single allocation, which results in a lot less garbage and a increased execution speed.