Re: Fastcode CompareStr B&V 1.1
- From: "Eric W. Carman" <ewcarman@ _REMOVETHIS_ ecsoftwareconsulting.dot.com>
- Date: Fri, 9 Sep 2005 08:48:08 -0400
I noticed the special case that Pierre has optimized for too. A great catch
to be sure. I admit that it never even crossed my mind.
As to the "real world", it is hard to say. The things my applications seem
to compare (alpha-numeric product numbers for example) don't have a lot of
variation in the highest order character, but I'm not sure that can be
extrapolated to the general use of this function. Hopefully others will
chime in and lend their experiences.
Best Regards,
Eric
"Dennis" <marianndkc@xxxxxxxxxxxxxxx> wrote in message
news:43216f4c$1@xxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Pierre, Eric etc.
>
> I am interested in what makes Pierre's functions so much faster than mine.
> It looks to me as the first algorithm tweak he uses is to take advantage
> of
> the fact that all non-nil AnsiStrings contains one character, namely the
> zero terminator. Then you can compare first chars without reading the
> string
> lengths first. Many of the strings in the benchmark are different in the
> first char and your algorithm becomes very fast in these cases. I totally
> missed this possible optimization when I wrote my functions ;-)
>
> Is this correctly noticed by me?
>
> Is the amount of strings in the benchmark that are different in the first
> char realistic compared to strings that are compared in the real world?
>
> Best regards
> Dennis
>
>
.
- References:
- Fastcode CompareStr B&V 1.1
- From: Dennis
- Re: Fastcode CompareStr B&V 1.1
- From: Dennis
- Re: Fastcode CompareStr B&V 1.1
- From: Dennis
- Fastcode CompareStr B&V 1.1
- Prev by Date: Re: Fastcode CompareStr B&V 1.1
- Next by Date: AMD64's Two-Byte Near-Return RET Instruction
- Previous by thread: Re: Fastcode CompareStr B&V 1.1
- Next by thread: Re: Fastcode CompareStr B&V 1.1
- Index(es):
Relevant Pages
|