Message-ID: <8d5cce64d7413eff04c5595a0a80d2b5a809e2fe.camel@j-davis.com>
Subject: Re: micro-optimizing json.c
From: Jeff Davis <pgsql@j-davis.com>
To: Nathan Bossart <nathandbossart@gmail.com>, Joe Conway
 <mail@joeconway.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, 
 Davin Shearer <davin@apache.org>, PostgreSQL-development
 <pgsql-hackers@postgresql.org>
Date: Thu, 07 Dec 2023 15:43:47 -0800
In-Reply-To: <20231207231251.GB3359478@nathanxps13>
References: <20231207231251.GB3359478@nathanxps13>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/8d5cce64d7413eff04c5595a0a80d2b5a809e2fe.camel%40j-davis.com>
Precedence: bulk

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.=C2=A0 O=
n
> my
> laptop, I see a 20% speedup from ~23.6s to ~18.9s for this test.

Nice improvement. The use of (len =3D ...) 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