[Xapian-tickets] [Xapian] #782: Improve encode_length() performance

[Xapian]

#782: Improve encode_length() performance
----------------------------+-----------------------------
 Reporter:  Kronuz          |             Owner:  olly
     Type:  enhancement     |            Status:  assigned
 Priority:  normal          |         Milestone:
Component:  Backend-Remote  |           Version:
 Severity:  minor           |        Resolution:
 Keywords:                  |        Blocked By:
 Blocking:                  |  Operating System:  All
----------------------------+-----------------------------

Comment (by olly):

 I've so far gone through and converted the encoding side to `pack_uint()`
 - based on that I don't believe there's anything significant in Xapian's
 remote protocol which uses `encode_length()` where the value could never
 be > 255.

 There are places where it'll always fit in a byte for most of the current
 backends (the disk-based backends currently impose a term length limit a
 bit under 255, though that could change in future and inmemory doesn't
 have such a limit).

 However, I noticed that for a lot of the current uses of `encode_length()`
 are for the final entry in a string, and there we can use
 `pack_uint_last()` instead, which just stores the bytes from the integer
 up to the most significant non-zero byte.  Adding that to your benchmark I
 find it's the same speed as "Char" for GCC (-O2 or -O3) and for clang at
 -O3.  For clang at -O2 it's in between in speed:

 {{{
 BM_EncodeLength_Pack              23 ns         23 ns   30996598
 BM_EncodeLength_PackLast          18 ns         18 ns   40014832
 BM_EncodeLength_Char              10 ns         10 ns   70941804
 }}}

 So we should probably use that where we can.  It's also a slightly more
 compact encoding than `pack_uint()`.

--
Ticket URL: <https://trac.xapian.org/ticket/782#comment:15>
Xapian <https://xapian.org/>
Xapian