Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection;
От | Tom Lane |
---|---|
Тема | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; |
Дата | |
Msg-id | 11724.1226864639@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Pl/Perl function: Speed of the First time executing pl/perl function in connection; (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Pl/Perl function: Speed of the First time executing
pl/perl function in connection;
|
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > Tom Lane wrote: >> ... which leads to the conclusion that those random little startup things >> plperl does are just unbelievably expensive. > I suspect much of this time is taken in loading perl modules, (strict, > Safe, utf8, SPI among others), not in anything very special that we do.: I did some more poking and determined that on my machine, it takes about 14 msec to do plperl_init_interp and about 20 msec to do plperl_safe_init. Most of the former time (over 9 msec) is going into the perl_parse call; I'm not entirely sure why it's so expensive. Taking out the SPI module initialization does *not* save anything worth noticing. I tried trimming various bits of the PERLBOOT script and the only thing that made a dent was removing "use vars qw(%_SHARED);", but that was still not much (about 5 msec). In plperl_safe_init, it's entirely clear that "require Safe" is the expensive part; I can duplicate a comparable time expenditure when doing that from the command line. So about the only real answer is going to be preloading. It seems worth considering that on machines where can_run_two is true, we should just go ahead and initialize both interps at _PG_init time, so as to allow the "require Safe" overhead to be bought back by preloading. I'm not sure how to deal with the UTF8 hack though. regards, tom lane
В списке pgsql-hackers по дате отправления: