[fpc-devel] TFPHashList (Was: Alternative parsers)

Sergei Gorelkin sergei_gorelkin at mail.ru
Wed Oct 20 16:04:30 CEST 2010


Alexander Klenin пишет:
> On Thu, Oct 21, 2010 at 00:03, Sergei Gorelkin <sergei_gorelkin at mail.ru> wrote:
>> Alexander Klenin пишет:
>> Running the test, I get quite opposite results:
>>
>> 0.750 sec
>> 0.766 sec
>> short add:  1.829 sec
>> short find: 0.781 sec
>> ansi add:   1.750 sec
>> ansi find:  1.406 sec
>>
>> The only modifications I made to the test is added printing separate numbers
>> for 'find' and 'add', and printing labels. Modified test is attached.
> 
> What CPU? I have Core i3 540.
> 
Mine is Core2Duo E7200.

>> Although theoretically Find() should show no difference at all, because it
>> performs the same operations on the same data. IOW, the difference seen is
>> caused either by CPU cache effects, or by bugs in testing.
> 
> I suspect that the main culprit may be the relatively slow
> implementation of built-in AnsiString operator=.
> ShortString code contains a strange construct in InternalFind function,
> clearly designed to bypass built-in operator=.
> I removed that construct during ansistring conversion.
> 
Ah, that's an artifact from old days. It was removed a while ago from compiler's cclasses.pas, but 
nobody took care to promote those changes to contnrs.pas. Probably I should do that.

>> No difference between the first two numbers (IntToStr for ShortString and
>> AnsiString) is also quite suspicious...
> 
> This is probably because the time is dominated by the conversion itself.
> IOW, IntToStr is so slow that string type does not matter in comparison.
> 

The conversion itself is just "divide by 10, add ord('0')" per digit. Should be that way, at least.
It is a point to have a closer look at (for me :).

Regards,
Sergei



More information about the fpc-devel mailing list