Re: micro-optimizing json.c
От | Nathan Bossart |
---|---|
Тема | Re: micro-optimizing json.c |
Дата | |
Msg-id | 20231208032028.GA3468226@nathanxps13 обсуждение исходный текст |
Ответ на | Re: micro-optimizing json.c (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: micro-optimizing json.c
|
Список | pgsql-hackers |
On Thu, Dec 07, 2023 at 07:40:30PM -0500, Tom Lane wrote: > Hmm ... I think that might not be the way to think about it. What > I'm wondering is why we need a test as expensive as IsValidJsonNumber > in the first place, given that we know this is a numeric data type's > output. ISTM we only need to reject "Inf"/"-Inf" and "NaN", which > surely does not require a full parse. Skip over a sign, check for > "I"/"N", and you're done. > > ... and for that matter, why does quoting of Inf/NaN require > that we apply something as expensive as escape_json? Several other > paths in this switch have no hesitation about assuming that they > can just plaster double quotes around what was emitted. How is > that safe for timestamps but not Inf/NaN? I did both of these in v2, although I opted to test that the first character after the optional '-' was a digit instead of testing that it was _not_ an 'I' or 'N'. I think that should be similar performance-wise, and maybe it's a bit more future-proof in case someone invents some new notation for a numeric data type (/shrug). In any case, this seems to speed up my test by another half a second or so. I think there are some similar improvements that we can make for JSONTYPE_BOOL and JSONTYPE_CAST, but I haven't tested them yet. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: