* The Hermit Hacker <scrappy@hub.org> [000119 12:51] wrote:
> On Wed, 19 Jan 2000, Bruce Momjian wrote:
>
> > [Charset ISO-8859-1 unsupported, filtering to ASCII...]
> > > On 2000-01-18, Bruce Momjian mentioned:
> > >
> > > > Can you run our keywords.c using our method and gperf and see if there
> > > > is any speed difference?
> > >
> > > It seems to have a speed advantage of about 2.5. But in practice that
> > > means that 1 million words take half a second. It's not a big deal to me,
> > > I was just wondering before I throw it out. I guess it really only makes a
> > > difference for compilers, which operate on 1000+ lines.
> > >
> >
> > The big difference may be that the compiler has variables/types that are
> > added dynamically while running, while our list is static. Insert time
> > for our types is zero because we don't add SQL keywords at runtime.
>
> I'm curious...does it hurt us any to do this? Like, will it slow things
> down? Is the end result cleaner, for neglible speed improvements?
You can pick up a copy of my test at:
http://www.freebsd.org/~alfred/gperf.tgz
It should compile two programs 'gperf' and 'norm', I was able to get
almost a 100% speed improvement:
~/gperf % time ./gperf
./gperf 0.49s user 0.00s system 100% cpu 0.489 total
~/gperf % time ./norm
./norm 0.91s user 0.00s system 99% cpu 0.918 total
One thing you'll want to consider is the overall application of this,
if the potentially sparse tables that gperf creates causes us to fault
in extra cache pages it may not be so cool.
I'm also pretty sure someone more proficient with hash tables and gperf
in particular could get better results than I did, I sort of guessed
at gperf command line switches until one seemed to work.
also... to accomplish the gperf testing I do a strlen on each word,
over and over to simulate the need for it (as gperf needs that)
however if the strlen is already available in the parser at this
time, i'm pretty sure it would be even faster.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]