Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) |
Дата | |
Msg-id | 20170417165315.7jtyajt7unjp56ii@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Cutting initdb's runtime (Perl question embedded) (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)) |
Ответы |
Re: [HACKERS] Cutting initdb's runtime (Perl question embedded)
|
Список | pgsql-hackers |
On 2017-04-17 17:49:54 +0100, Dagfinn Ilmari Mannsåker wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > There's certainly lots more that could be done in the genbki code, > > but I think all we can justify at this stage of the development > > cycle is to get the low-hanging fruit for testing speedups. > > I threw Devel::NYTProf at it and picked some more low-hanging fruit. > Attached are separate patches for each change, and here are the runtimes > of genbki.pl and Gen_fmgrtab.pl, respectively, after each patch > (averages of 5 runs, in millseconds): > > master (b6dd1271): 355, 182 > > 1: Avoid unnecessary regex captures: 349, 183 > 2: Avoid repeated calls to SplitDataLine: 316, 158 > 3: Inline SplitDataLine: 291, 141 > 4: Inline check_natts: 287, 141 > > Together they shave 68ms or 19.2% off the runtime of genbki.pl and 41ms > or 22.5% off the runtime of Gen_fmgrtab.pl I'm a bit doubtful about improving the performance of genbki at the cost of any sort of complication - it's only executed during the actual build, not during initdb... I don't see much point in doing things like 3) and 4), it's just not worth it imo. - Andres
В списке pgsql-hackers по дате отправления: