| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Davin Shearer <davin(at)apache(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: micro-optimizing json.c |
| Date: | 2023-12-07 23:43:47 |
| Message-ID: | 8d5cce64d7413eff04c5595a0a80d2b5a809e2fe.camel@j-davis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2023-12-07 at 17:12 -0600, Nathan Bossart wrote:
> Here's a patch that removes a couple of strlen() calls that showed up
> prominently in perf for a COPY TO (FORMAT json) on 110M integers. On
> my
> laptop, I see a 20% speedup from ~23.6s to ~18.9s for this test.
Nice improvement. The use of (len = ...) in a conditional is slightly
out of the ordinary, but it makes the conditionals a bit simpler and
you have a comment, so it's fine with me.
I wonder, if there were an efficient cast from numeric to text, then
perhaps you could avoid the strlen() entirely? Maybe there's a way to
use a static buffer to even avoid the palloc() in get_str_from_var()?
Not sure these are worth the effort; just brainstorming.
In any case, +1 to your simple change.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2023-12-08 00:34:57 | Re: Improve WALRead() to suck data directly from WAL buffers when possible |
| Previous Message | Nathan Bossart | 2023-12-07 23:12:51 | micro-optimizing json.c |