[PATCH grout] api: optimize send small payloads

[Morten Brørup]

> From: Robin Jarry [mailto:rjarry at redhat.com]
> Sent: Monday, 6 July 2026 17.13
> 
> Morten Brørup, Jul 06, 2026 at 12:41:
> >> Did you measure any improvement after this patch?
> >
> > I did not profile it, no. The send() syscall is quite expensive, so
> > combining two calls into one should give Grout API transactions
> > a measurable performance boost.
> 
> OK, in that case (unless we can show a reasonable improvement), I would
> prefer to keep the code simpler.

Ack.
The DPDK community also likes to see numbers for performance improvement patches.

> 
> You may save one write() call, but the other side needs to read() twice
> anyway, once to get the header (which tells the payload length) and
> a second time for the payload (if any).

I considered optimizing read() too, but didn't even start on that.

> 
> > The changes related to the bufferevent_write() lib call were added
> > mainly for symmetry. So I set a much lower merge threshold. I think
> > the performance difference negligible. BTW, my changes here also
> fixes
> > a bug: The payload was unconditionally written, regardless of writing
> > the header failed.
> 
> The main concern would be on the daemon side but as you pointed out,
> this is already dealt with in the bufferevent_write() abstraction.
> Let's
> not add another level of (conditional) buffering.
> 
> We could fix that extraneous write, but I don't think it causes any
> issue. If one write fails, we'll get notified in event_cb() and grout
> will close the connection anyway.

OK.
I didn't look into the details of the bufferevent_write() implementation.

> 
> > Honestly, I just started familiarizing myself with Grout a few weeks
> > ago, and stumbled across this (inefficiency of calling send() twice)
> > while trying to learn about Grout's API mechanisms. So I thought I'd
> > add this simple optimization.

Thank you for the detailed feedback, Robin.

I might play around with it some more (also for the learning experience), and see if I can achieve measurable benefits.
For now, I have marked the patch as Changes Requested.