perf: Optimize column_encryption_policy checks in recv_results_rows (1.7x speedup for Cython, 1.2x for Python)

[mykaul]

Optimize column_encryption_policy checks in the result parsing hot path.

Previously, every decoded value checked ce_policy and ce_policy.contains_column(coldesc) even when no encryption policy was configured (the common case). This PR splits the parsing into two code paths — unpack_plain_row() and unpack_col_encrypted_row() — and branches once per result set instead of per value.

Changes:

• protocol.py: Split recv_results_rows() pure-Python path
• obj_parser.pyx: Split TupleRowParser.unpack_row() into unpack_plain_row() / unpack_col_encrypted_row(), with @boundscheck(False) / @wraparound(False) and try/except moved outside the per-column loop
• ListParser / LazyParser / row_parser: Branch once on column_encryption_policy
• numpy_parser.pyx: NumpyParser.parse_rows() raises NotImplementedError when column encryption is configured (it has no decryption support)
• query.py: Same split-path optimization in BoundStatement.bind()

Benchmark (Cython ListParser, 10k rows, no encryption policy)

                      Master            PR            Speedup
2 cols (Int32+UTF8):  3.67 ms           2.08 ms       1.77x  (2.7M -> 4.8M rows/s)
10 cols (all Int32):  8.37 ms           5.18 ms       1.62x  (1.2M -> 1.9M rows/s)

Improvement comes from eliminating per-value overhead in the hot loop:

• ce_policy and ce_policy.contains_column(coldesc) truthiness check
• coldesc = desc.coldescs[i] lookup (not needed in plain path)
• try/except per value moved outside the loop
• @cython.boundscheck(False) / @cython.wraparound(False) decorators

Fixes: #582

Pre-review checklist

• I have split my patch into logically separate commits.
• All commit messages clearly explain what they change and why.
• I added relevant tests for new features and bug fixes.
• All commits compile, pass static checks and pass test.
• PR description sums up the changes and reasons why they should be introduced.
• I have provided docstrings for the public items that I want to introduce.
• I have adjusted the documentation in ./docs/source/.
• I added appropriate Fixes: annotations to PR description.

[mykaul]

CI failure is unrelated, and I've seen it happening on too many PRs already :-/

[dkropachev]

numpy_parser.pyx, parsing.pyx also needs to be fixed

[mykaul]

numpy_parser.pyx, parsing.pyx also needs to be fixed

It wasn't clear to me what needs to fixing there:
numpy - it doesn't use/call column_encryption
parsing.pyx - there's just 'not implemented' functions there.

[dkropachev]

numpy_parser.pyx, parsing.pyx also needs to be fixed

It wasn't clear to me what needs to fixing there: numpy - it doesn't use/call column_encryption parsing.pyx - there's just 'not implemented' functions there.

Instead of changing only TupleRowParser class you need to do similar changes to ColumnParser and RowParser and all their implementations: ListParser, LazyParser and NumpyParser, you will discover that NumpyParser disregards column_encryption_policy which means that it does not work properly when when columns are encrypted, have a plug there that throwing NotImplementedError.
In total all Parser implementation classes should contain implementations for:

    cpdef parse_plain_rows(self, BytesIOReader reader, ParseDesc desc)

    cpdef parse_enc_rows(self, BytesIOReader reader, ParseDesc desc)

While Abstract classes:

cdef class ColumnParser:
    cpdef parse_rows(self, BytesIOReader reader, ParseDesc desc):
        if desc.column_encryption_policy:
            return self.unpack_enc_row(reader, desc)
        return self.unpack_plain_row(reader, desc)

    cpdef parse_plain_rows(self, BytesIOReader reader, ParseDesc desc)

    cpdef parse_enc_rows(self, BytesIOReader reader, ParseDesc desc)

[mykaul]

numpy_parser.pyx, parsing.pyx also needs to be fixed

It wasn't clear to me what needs to fixing there: numpy - it doesn't use/call column_encryption parsing.pyx - there's just 'not implemented' functions there.

Instead of changing only TupleRowParser class you need to do similar changes to ColumnParser and RowParser and all their implementations: ListParser, LazyParser and NumpyParser, you will discover that NumpyParser disregards column_encryption_policy which means that it does not work properly when when columns are encrypted, have a plug there that throwing NotImplementedError. In total all Parser implementation classes should contain implementations for:

Let me see if I understand this:

• TupleRowParser - Implemented unpack_ce_row() and unpack_row()
• ColumnParser - its parse_rows() creates a TupleRowParser object - and then I call its unpack_ce_row() / unpack_row()
• RowParser- its unpack_row() is raising NotImplementedError - I'm not sure I should change this in this PR?
• ListParser - its parse_rows() creates a TupleRowParser object - and then I call its unpack_ce_row() / unpack_row()
• LazyParser - its parse_rows() calls parse_rows_lazy() - which creates a TupleRowParser object - and then I call its unpack_ce_row() / unpack_row()
• NumpyParser its parse_rows() calls its _parse_rows() which completely ignores encryption and calls unpack_row() - but I have no idea where it's implemented. BUT - I'm not introducing a regression here, no?
• BoundStatement.bind() - added in the last commit in the series.

Is that an accurate representation?

    cpdef parse_plain_rows(self, BytesIOReader reader, ParseDesc desc)

    cpdef parse_enc_rows(self, BytesIOReader reader, ParseDesc desc)

I'm not sure I understand the interaction between Python and Cython - I was not going to change the interfaces whatsoever.

While Abstract classes:

cdef class ColumnParser:
    cpdef parse_rows(self, BytesIOReader reader, ParseDesc desc):
        if desc.column_encryption_policy:
            return self.unpack_enc_row(reader, desc)
        return self.unpack_plain_row(reader, desc)

    cpdef parse_plain_rows(self, BytesIOReader reader, ParseDesc desc)

    cpdef parse_enc_rows(self, BytesIOReader reader, ParseDesc desc)

You raise a good point about the names of the functions - that can clearly be more clear with 'plain' and 'encrypted' in them! I'll fix that.

[mykaul]

You raise a good point about the names of the functions - that can clearly be more clear with 'plain' and 'encrypted' in them! I'll fix that.

Done in latest commit. I think it's ready for re-review.

[mykaul]

CI failure seems like known issue #446

[mykaul]

Can this be reviewed? In my (limited) testing, it did show some nice improvement. It's just a branch or so, but apparently, was impacting to some degree the performance.

[mykaul]

Rebased to origin/master + Pure-Python benchmark

Rebased cleanly onto current origin/master (no conflicts). All 16 protocol unit tests + 112 other unit tests pass.

Pure-Python recv_results_rows decode benchmark

The original PR description covers Cython ListParser performance. Here are the pure-Python path numbers (10,000 rows, no column_encryption_policy, best of 5 runs, CPU pinned to single core):

Config                        Master (ms)    PR (ms)  Speedup   Master rows/s       PR rows/s
----------------------------------------------------------------------------------------------------
2 cols (Int32+UTF8)               15.61 ms    12.78 ms    1.22x       640,768/s       782,702/s
10 cols (Int32+UTF8)              41.32 ms    34.21 ms    1.21x       241,999/s       292,289/s
2 cols (all Int32)                13.54 ms    11.26 ms    1.20x       738,461/s       888,109/s
10 cols (all Int32)               41.01 ms    34.46 ms    1.19x       243,837/s       290,209/s

Consistent 1.19–1.22x speedup on the pure-Python path by eliminating:

• ColDesc namedtuple allocation per column (N allocations per query)
• Per-value column_encryption_policy and ce_policy.contains_column(coldesc) truthiness check
• Per-value col_desc lookup from the col_descs list
• 3-way zip(row, column_metadata, col_descs) → 2-way zip(row, column_metadata)

Environment: Python 3.14.3, no Cython .so for protocol.py.

[mykaul]

Updated benchmarks — Cython and Pure-Python paths

All benchmarks: 10,000 rows, no column_encryption_policy (common case), best of 5 runs, CPU pinned to single core (core 15), 1000 iters (Cython) / 200 iters (pure-Python), with warm-up. Python 3.14.3, Cython 3.2.4.

Cython ListParser (obj_parser.pyx + row_parser.pyx)

Config                       Master ns/col-row    PR ns/col-row  Speedup
-------------------------------------------------------------------------
2 cols (Int32+UTF8)                 91.4 ns           81.2 ns     1.13x
10 cols (Int32+UTF8)                88.0 ns           74.1 ns     1.19x
2 cols (all Int32)                  58.6 ns           45.1 ns     1.30x
10 cols (all Int32)                 38.5 ns           28.4 ns     1.36x

Pure-Python (protocol.py recv_results_rows)

Config                       Master ns/col-row    PR ns/col-row  Speedup
-------------------------------------------------------------------------
2 cols (Int32+UTF8)                788.7 ns          649.4 ns     1.21x
10 cols (Int32+UTF8)               432.5 ns          355.1 ns     1.22x
2 cols (all Int32)                 680.8 ns          564.5 ns     1.21x
10 cols (all Int32)                449.0 ns          358.2 ns     1.25x

Summary

Path	Speedup range
Cython ListParser	1.13–1.36x
Pure-Python decode	1.21–1.25x

Cython gains are larger for Int32-only workloads (up to 1.36x) because the per-column overhead eliminated by this PR is a bigger fraction of the total when the deserialization itself is cheap (Int32 = single struct.unpack). Mixed Int32+UTF8 workloads show a smaller but still significant improvement.