Re: Scanner performance (was Re: 7.3 schedule)

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Top ten calls:

> % cumulative self self total
> time seconds seconds calls ms/call ms/call name
> 36.95 9.87 9.87 74882482 0.00 0.00 pq_getbyte
> 22.80 15.96 6.09 11 553.64 1450.93 pq_getstring
> 13.55 19.58 3.62 11 329.09 329.10 scanstr
> 12.09 22.81 3.23 110 29.36 86.00 base_yylex
> 4.27 23.95 1.14 34 33.53 33.53 yy_get_previous_state
> 3.86 24.98 1.03 22 46.82 46.83 textin
> 3.67 25.96 0.98 34 28.82 28.82 myinput
> 1.83 26.45 0.49 45 10.89 32.67 yy_get_next_buffer
> 0.11 26.48 0.03 3027 0.01 0.01 AllocSetAlloc
> 0.11 26.51 0.03 129 0.23 0.23 fmgr_isbuiltin

Interesting. This should be taken with a grain of salt however: gprof's
call-counting overhead is large enough to skew the results on many
machines (ie, routines that are called many times tend to show more than
their fair share of runtime). If your profiler does not show the
counter subroutine ("mcount" or some similar name) separately, you
should be very suspicious of where the overhead time is hidden.

For comparison you might want to check out some similar numbers I
obtained awhile back:
http://archives.postgresql.org/pgsql-hackers/2001-12/msg00076.php
(thanks to Barry Lind for reminding me about that ;-)). That test
showed base_yylex/addlit/scanstr as costing about twice as much as
pg_getstring/pq_getbyte. Probably the truth is somewhere in between
your measurements and mine.

In any case it does seem that some micro-optimization in the vicinity of
the scanner's per-character costs, ie, pq_getbyte, addlit, etc would be
worth the trouble.

regards, tom lane