Hi again, Ignore previous patch, new correct version attached, that also keeps track of if the buf-field is in use or not.
Seems like your idea gives a signifiant speed-up! On my machine, numeric_in() is 22% faster! I ran a benchmark with 100 tests measuring execution-time of numeric_in() with two significant digits time precision. Benchmark: CREATE EXTENSION pit; SELECT count(pit.async('numeric_in','{1234,0,-1}',2)) FROM generate_series(1,100); CALL pit.work(true); SELECT format('%s(%s)',pit.test_params.function_name, array_to_string(pit.test_params.input_values,',')), pit.pretty_time(pit.tests.final_result), count(*) FROM pit.tests JOIN pit.test_params USING (id) GROUP BY 1,2 ORDER BY 1,2; HEAD: format | pretty_time | count -----------------------+-------------+------- numeric_in(1234,0,-1) | 31 ns | 34 numeric_in(1234,0,-1) | 32 ns | 66 (2 rows) 0002-fixed-buf.patch: format | pretty_time | count -----------------------+-------------+------- numeric_in(1234,0,-1) | 24 ns | 4 numeric_in(1234,0,-1) | 25 ns | 71 numeric_in(1234,0,-1) | 26 ns | 25 (3 rows) The benchmark results was produced with: https://github.com/joelonsql/pg-timeit Now, the question is how big of a fixed_buf we want. I will run some more benchmarks. /Joel On Sun, Feb 19, 2023, at 20:54, Joel Jacobson wrote: > On Fri, Feb 17, 2023, at 21:26, Andres Freund wrote: >> Removing the free_var()s from numeric_add_opt_error() speeds it up from >> ~361ms >> to ~338ms. > > I notice numeric_add_opt_error() is extern and declared in numeric.h, > called from e.g. timestamp.c and jsonpath_exec.c. Is that a problem, > i.e. is there a risk it could be used in a for loop by some code > outside Numeric? > >> This code really needs some memory management overhead reduction love. Many >> allocation could be avoided by having a small on-stack "buffer" that's used >> unless the numeric is large. > > Nice idea! > Could something like the attached patch work? > > /Joel > Attachments: > * 0001-fixed-buf.patch -- Kind regards, Joel
0002-fixed-buf.patch
Description: Binary data