Re: Faster way of making long string?

On Mon, 25 Apr 2005 19:19:35 +0200, Ekkehard Domning <edo@xxxxxxxx>
wrote:

>Hello J
>
>J French wrote:
>> On Sun, 24 Apr 2005 19:51:01 +0200, Ekkehard Domning <edo@xxxxxxxx>
>>>as You see, Ian made a test and shows that the stringlist method is running at
>>>double speed as his approach. I would define "inefficiency" a bit different.
>
>> Check Chris Willig's example
>> - and that could be made faster by aggressive increasing of the buffer
>> size (eg: Len := Len * 2 )
>
>Agree. I posted a fast example too, please take a look there.

Yes - your use of ShortString was a very good idea
- that will be very fast and will never move around

- the pre-calculation surprized me - rather cunning
(it needs to take negatives into account)

Rather than IntToStr I would use: Str( I, S )
- it saves a string creation in IntToStr
- also having drilled into IntToStr it seems to be doing rather a lot
of work

>>>At the end of the discussion comes the question about the code. Should the
>>>code be "fast" or "maintainable".
>> It should be both
>> - but even more important, it should not be obscure
>
>I have seen very fast code, but nobody could understand. So if an error occour
>it becomes "obscure". So agree too.

That is one of my nightmares

>> - creating a TStringList when you want one long string is 'indirect'
>
>True, but the way is easy. Make strings from all numbers, than build one long
>string from the small strings. Yes, there is a lot work on the heap in the
>background, and yes there is nearly twice as much memory needed than in the
>fast example.
>
>> This is not meant to be personal, but I have noticed that a lot of
>> Delphi coders are not really that familiar with working with Strings.
>> - because they are really a fairly recent addition to the language
>they should become fammilar, its really a very good choice
>
>> Where you would use a TStringList I would probably use a dynamic array

>also not very old stuf :-)

Yes - they came in with D4 - very nice

>...
>
>> Obviously, I have a large library of string manipulation routines that
>> started life well before Delphi - in DOS BASIC and ASM
>I agree that old handy tools could be a very comfortable. A new tool needs
>unpacking, reading instruction, you have to go in the work room find a cable,
>etc. In the meantime the old tool has finished the work :-)

Absolutely !
.

Relevant Pages

  • Re: Fastcode IntToStr B&V version 0.29
    ... It seems to me that new validation is very strong :-) ... IntToStr was passed a value of 1 digits and string of length 2, ...
    (borland.public.delphi.language.basm)
  • Re: Fastcode Voting - IntToStr Result Length Rule
    ... would one say that an IntToStr function that always allocates 10 bytes for the result string be smaller than one allocating what is needed? ... I see no connection between code size and the size of the result string. ... You'll have ended up with something that is not only slower but will also use require more memory to operate in practice. ...
    (borland.public.delphi.language.basm)
  • Re: New FastCode Uppercase and Lowercase functions
    ... > Hi John ... >> IntToStr function, this resulted in a 300% speed improvement. ... > string - kind of. ... Since the allocation takes approx 50% of the total function ...
    (borland.public.delphi.language.basm)
  • Re: Fastcode IntToStr Validation
    ... > IntToStr64 B&V to confirm that functions do not overallocate memory ... > for the result string. ... > called within any IntToStr function whenever ... > Note - This validation only checks that the result string is resized ...
    (borland.public.delphi.language.basm)
  • Fastcode IntToStr Validation
    ... I think we need to add further validation to the IntToStr and IntToStr64 B&V ... Note - This validation only checks that the result string is resized when is ... ResizeExpected: Boolean; ...
    (borland.public.delphi.language.basm)