From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: strncmp->memcmp when we know the shorter length |
Date: | 2010-12-22 18:19:51 |
Message-ID: | 20101222181951.GA1325@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Dec 21, 2010 at 10:15:41PM -0500, Robert Haas wrote:
> A little benchmarking reveals that on my system (MacOS X 10.6.5) it
> appears that strncmp() is faster for a 4 character string, but
> memcmp() is faster for a 5+ character string.
Good call; I hadn't considered that possibility.
> So I think most of
> these are pretty clear wins, but I have reverted the changes to
> src/backend/tsearch because I'm not entirely confident that lexemes
> and affixes will be long enough on average for this to be a win there.
> Please feel free to resubmit that part with performance results
> showing that it works out to a win. Some of the ltree changes
> produced compiler warnings, so I omitted those also. Committed the
> rest.
Thanks for the quick review and commit. I'm not acquainted with the performance
significance of the tsearch and ltree call sites. Leaving those as-is makes
sense to me.
nm
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2010-12-22 18:24:00 | Re: plperlu problem with utf8 |
Previous Message | David Fetter | 2010-12-22 16:53:46 | Re: How much do the hint bits help? |