plpython3 perf
in [PgSql]
|
Prev: HS/SR and smart shutdown
Next: [HACKERS] is any reason why we cannot cast from record (row) to typed row?
From: James William Pye on 20 Jan 2010 21:32 On Jan 14, 2010, at 2:03 PM, Joshua D. Drake wrote: > What I would (as a non hacker) would look for is: > > (1) Generalized benchmarks between plpython(core) and plpython3u > > I know a lot of these are subjective, but it is still good to see if > there are any curves or points that bring the performance of either to > light. k, it was pretty much as expected. However, the surprise for me was that @pytypes didn't perform as terribly as I expected it to. I imagine it's impact may become more noticeable with more parameters, but, nonetheless, I was surprised. I didn't do any SRF tests, but the installations are still setup, so if anyone really wants to see that, it shouldn't take long to do. Apologies ahead of time for the lack pretty graphs. =) I used two different builds/installations of PG to test as the PL names conflict. Both were compiled with the following CFLAGS(pg_config output): -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv Both PLs were built against the same build of Python(recent svn update of release31-maint): Python 3.1.1+ (release31-maint:77585M, Jan 17 2010, 10:29:13) [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin I ran each of the test files a few times against the target installation, but I only attached one of each to this message. (Primarily, multiple runs to filter out any spurious spikes.) The source SQL and output files are attached. rawtest.sql.out is the output for raw data objects(native typing). pytypestest.sql.out is the output of the @pytypes test(native typing with conversion overhead). plpythontest.sql.out is the output for core's plpython(conversion). A few samples from the output files are included inline below. Each volatile function is called 100,000 times from a COUNT() aggregate, and the duration is measured using psql's \timing. Most of the functions simply return the first parameter given to it. The functions are ran inside a transaction because plpython3 does some cache clears(linecache) and GC at the end of transactions. The parameter type, if any, is indicated by the label: noparams: raw: 125ms pytypes: 372ms (base overhead, it would appear) plpython: 309ms oneint2: raw: 140ms pytypes: 684ms plpython: 750ms oneint8: raw: 145ms pytypes: 676ms plpython: 718ms text_large: raw: 271ms pytypes: 2766ms plpython: 2310ms composite: raw: 235ms pytypes: 795ms (N/A, no conversion done, but takes a bit of a hit anyways) plpython: 1654ms
From: "Joshua D. Drake" on 25 Jan 2010 14:12
On Wed, 2010-01-20 at 19:32 -0700, James William Pye wrote: > Apologies ahead of time for the lack pretty graphs. =) > > I used two different builds/installations of PG to test as the PL names conflict. Both were compiled with the following CFLAGS(pg_config output): > > -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv > > Both PLs were built against the same build of Python(recent svn update of release31-maint): > > Python 3.1.1+ (release31-maint:77585M, Jan 17 2010, 10:29:13) > [GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin > This is great stuff. Thanks for your diligence. > I ran each of the test files a few times against the target installation, but I only attached one of each to this message. (Primarily, multiple runs to filter out any spurious spikes.) > > The source SQL and output files are attached. > > rawtest.sql.out is the output for raw data objects(native typing). > pytypestest.sql.out is the output of the @pytypes test(native typing with conversion overhead). > plpythontest.sql.out is the output for core's plpython(conversion). > > A few samples from the output files are included inline below. > > Each volatile function is called 100,000 times from a COUNT() aggregate, and the duration is measured using psql's \timing. Most of the functions simply return the first parameter given to it. The functions are ran inside a transaction because plpython3 does some cache clears(linecache) and GC at the end of transactions. > > The parameter type, if any, is indicated by the label: > > noparams: > > raw: 125ms > pytypes: 372ms (base overhead, it would appear) > plpython: 309ms > > oneint2: > > raw: 140ms > pytypes: 684ms > plpython: 750ms > > oneint8: > > raw: 145ms > pytypes: 676ms > plpython: 718ms > > text_large: > > raw: 271ms > pytypes: 2766ms > plpython: 2310ms > > composite: > > raw: 235ms > pytypes: 795ms (N/A, no conversion done, but takes a bit of a hit anyways) > plpython: 1654ms > > -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering Respect is earned, not gained through arbitrary and repetitive use or Mr. or Sir. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |