> On Jun 20, 2023, at 1:01 PM, Matthias van de Meent
> wrote:
>
> 0001 is copied essentially verbatim from [1] and reduces overhead in
> the registered block's length field where possible. It is included to
> improve code commonality between varcoded integer fields. See [1] for
> more details
> On 3 Jan 2024, at 15:15, Pavel Borisov wrote:
>
> Hi and Happy New Year!
>
> I've looked through the patches and the change seems quite small and
> justified. But at the second round, some doubt arises on whether this long
> patchset indeed introduces enough performance gain? I may be wro
Hi and Happy New Year!
I've looked through the patches and the change seems quite small and
justified. But at the second round, some doubt arises on whether this long
patchset indeed introduces enough performance gain? I may be wrong, but it
saves only several bytes and the performance gain would
On Mon, Sep 25, 2023 at 07:40:00PM +0200, Matthias van de Meent wrote:
> On Wed, 20 Sept 2023 at 07:06, Michael Paquier wrote:
>> #define COPY_HEADER_FIELD(_dst, _size)\
>> do {\
>> -if (remaining < _size)\
>> +
On Wed, 20 Sept 2023 at 07:06, Michael Paquier wrote:
>
> On Tue, Sep 19, 2023 at 12:07:07PM +0200, Matthias van de Meent wrote:
> > V5 is a rebased version of v4, and includes the latest patch from
> > "smaller XLRec block header" [0] as 0001.
>
> 0001 and 0007 are the meat of the changes.
Corre
On Tue, Sep 19, 2023 at 12:07:07PM +0200, Matthias van de Meent wrote:
> V5 is a rebased version of v4, and includes the latest patch from
> "smaller XLRec block header" [0] as 0001.
0001 and 0007 are the meat of the changes.
-#define XLR_CHECK_CONSISTENCY 0x02
+#define XLR_CHECK_CONSISTENCY (0
