refactor: introduce tuple abstraction

[tomdcc]

This replaces the use of byte[][] in a number of places with a Tuple class that wraps it. This is a necessary change to support doing anything other than blindly reading incoming data into a heap-allocated byte array.

The intended use-case is the flip side of #953. The actual functionality will follow in a subsequent PR if there's support for the refactor and feature.

[codecov-io]

Codecov Report

Merging #954 into master will increase coverage by 0.89%.
The diff coverage is 75.21%.

@@             Coverage Diff             @@
##             master    #954      +/-   ##
===========================================
+ Coverage      65.9%   66.8%   +0.89%     
- Complexity     3558    3717     +159     
===========================================
  Files           166     167       +1     
  Lines         15223   15994     +771     
  Branches       2458    2712     +254     
===========================================
+ Hits          10033   10685     +652     
- Misses         4023    4096      +73     
- Partials       1167    1213      +46

[vlsi]

@tomdcc , have you measured the overhead of new Tuple on the processing of a simple/complex SQL?

[davecramer]

date should probably be 2017 for a new file

[tomdcc]

Whoops! Fixed

[davecramer]

I think the abstraction is worthwhile even if it imposes a performance penalty. The question is at which point is it not worthwhile. So some benchmarking will be necessary

[vlsi]

Waiting for the performance tests

[tomdcc]

Ran the suggested benchmarks:

master vs tuple-class

Numbers are very close, slightly more have master faster than tuple-class, but the numbers are close enough that I think we're seeing noise.

[tomdcc]

@vlsi ping

[davecramer]

Is there any reason not to commit this ?

[vlsi]

Let's see how it goes.
I'm +-0 re this change.

[paplorinc]

Resolved the conflicts in #1701

[paplorinc]

Merged, please close

[davecramer]

rebased with PR 1701