Re: [PATCH] Optimize json_lex_string by batching character copying
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Jelte Fennema <Jelte.Fennema@microsoft.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Merlin Moncure <mmoncure@gmail.com>, Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>
Date: 2022-08-21T05:47:33Z
Lists: pgsql-hackers
Attachments
- 0001-json_lex_string-SIMD.patch (text/x-diff)
On Fri, Aug 19, 2022 at 01:42:15PM -0700, Nathan Bossart wrote: > On Fri, Aug 19, 2022 at 03:11:36PM +0700, John Naylor wrote: >> This is done. Also: >> - a complete overhaul of the pg_lfind8* tests >> - using a typedef for the vector type >> - some refactoring, name changes and other cleanups (a few of these >> could also be applied to the 32-byte element path, but that is left >> for future work) >> >> TODO: json-specific tests of the new path > > This looks pretty good to me. Should we rename vector_broadcast() and > vector_has_zero() to indicate that they are working with bytes (e.g., > vector_broadcast_byte())? We might be able to use vector_broadcast_int() > in the 32-bit functions, and your other vector functions already have a > _byte suffix. > > In general, the approach you've taken seems like a decent readability > improvement. I'd be happy to try my hand at adjusting the 32-bit path and > adding ARM versions of all this stuff. I spent some more time looking at this one, and I had a few ideas that I thought I'd share. 0001 is your v6 patch with a few additional changes, including simplying the assertions for readability, splitting out the Vector type into Vector8 and Vector32 (needed for ARM), and adjusting pg_lfind32() to use the new tools in simd.h. 0002 adds ARM versions of everything, which obsoletes the other thread I started [0]. This is still a little rough around the edges (e.g., this should probably be more than 2 patches), but I think it helps demonstrate a more comprehensive design than what I've proposed in the pg_lfind32-for-ARM thread [0]. Apologies if I'm stepping on your toes a bit here. [0] https://postgr.es/m/20220819200829.GA395728%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Commits
-
Speed up lexing of long JSON strings
- 0a8de93a48ce 16.0 landed
-
Add optimized functions for linear search within byte arrays
- e813e0e16852 16.0 landed
-
Build de-escaped JSON strings in larger chunks during lexing
- 3838fa269c15 16.0 landed
-
Simplify json lexing state
- 3de359f18f2b 16.0 landed