String conversions

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

String conversions

Ryan Joseph-2
I’m making some string helper functions and using ansistring as inputs (in case there are longer strings than 255 chars). What happens when you pass a short string as an ansistring? Does the compiler have to allocate a new ansistring or can it do some smart optimization?

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Jonas Maebe-3
On 25/06/2019 20:15, Ryan Joseph wrote:
> I’m making some string helper functions and using ansistring as inputs (in case there are longer strings than 255 chars). What happens when you pass a short string as an ansistring? Does the compiler have to allocate a new ansistring or can it do some smart optimization?

It has to allocate a new ansistring.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ryan Joseph-2


> On Jun 25, 2019, at 2:16 PM, Jonas Maebe <[hidden email]> wrote:
>
> On 25/06/2019 20:15, Ryan Joseph wrote:
>> I’m making some string helper functions and using ansistring as inputs (in case there are longer strings than 255 chars). What happens when you pass a short string as an ansistring? Does the compiler have to allocate a new ansistring or can it do some smart optimization?
>
> It has to allocate a new ansistring.

Ouch. That means I need to make lots of overloads. This is a prime candidate for generics then but I’m still waiting for my “implicitfunctionspecializations” modeswitch patch to be accepted.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ryan Joseph-2
In reply to this post by Jonas Maebe-3


> On Jun 25, 2019, at 2:16 PM, Jonas Maebe <[hidden email]> wrote:
>
> It has to allocate a new ansistring.

Another question: if I do "s += c” will the string reallocate memory for 1 character or is there an exponential growing function? If it does grow by one character at a time how can I reserve a certain capacity in advance?

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Jonas Maebe-3
On 25/06/2019 21:12, Ryan Joseph wrote:
>
> Another question: if I do "s += c” will the string reallocate memory for 1 character or is there an exponential growing function? If it does grow by one character at a time how can I reserve a certain capacity in advance?

Strings always contain the exact amount of memory required for their length.

If you need to do a lot of concatenations, you can use the
TStringBuilder class from sysutils for better performance.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Marco van de Voort-2
In reply to this post by Ryan Joseph-2
Op 2019-06-25 om 21:12 schreef Ryan Joseph:
>
>> On Jun 25, 2019, at 2:16 PM, Jonas Maebe <[hidden email]> wrote:
>>
>> It has to allocate a new ansistring.
> Another question: if I do "s += c” will the string reallocate memory for 1 character or is there an exponential growing function? If it does grow by one character at a time how can I reserve a certain capacity in advance?
An exponential growing function applied to all strings would have many
worse case behaviours, where it would eat up heaps of memory for
nothing. This is why it is better to have the programmer indicate it is
a growing string some how (or have a separate type, like TStringBuilder
mentioned by Jonas)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ryan Joseph-2


> On Jun 25, 2019, at 3:55 PM, Marco van de Voort <[hidden email]> wrote:
>
> An exponential growing function applied to all strings would have many worse case behaviours, where it would eat up heaps of memory for nothing. This is why it is better to have the programmer indicate it is a growing string some how (or have a separate type, like TStringBuilder mentioned by Jonas)

It would be nice if ansistring had a SetCapacity function to accompany SetLength but in leu of that I think making a new type is the best idea.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Marco van de Voort-3

Op 25/06/2019 om 21:58 schreef Ryan Joseph:
> An exponential growing function applied to all strings would have many worse case behaviours, where it would eat up heaps of memory for nothing. This is why it is better to have the programmer indicate it is a growing string some how (or have a separate type, like TStringBuilder mentioned by Jonas)
> It would be nice if ansistring had a SetCapacity function to accompany SetLength but in leu of that I think making a new type is the best idea.

I think we have enough string types
http://www.stack.nl/~marcov/delphistringtypes.txt

TStringbuilder is fine . Not every problem needs new syntax or types to
solve.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Michael Van Canneyt


On Wed, 26 Jun 2019, Marco van de Voort wrote:

>
> Op 25/06/2019 om 21:58 schreef Ryan Joseph:
>> An exponential growing function applied to all strings would have many
> worse case behaviours, where it would eat up heaps of memory for nothing.
> This is why it is better to have the programmer indicate it is a growing
> string some how (or have a separate type, like TStringBuilder mentioned by
> Jonas)
>> It would be nice if ansistring had a SetCapacity function to accompany
> SetLength but in leu of that I think making a new type is the best idea.
>
> I think we have enough string types
> http://www.stack.nl/~marcov/delphistringtypes.txt
>
> TStringbuilder is fine . Not every problem needs new syntax or types to
> solve.

I second that.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ben Grasset
On Wed, Jun 26, 2019 at 5:48 AM Michael Van Canneyt <[hidden email]> wrote:
I second that.

Michael.

I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. <a href="https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,lang:pascal,source:&#39;unit+output%3B%0A%0A%7B$mode+ObjFPC%7D%7B$H%2B%7D%0A%7B$modeswitch+AdvancedRecords%7D%0A%7B$ImplicitExceptions+Off%7D%0A%0Ainterface%0A%0Atype+%0A++TPCharEx+%3D+record%0A++++P:+PChar%3B%0A++++L:+SizeInt%3B%0A++++class+operator+:%3D(constref+LHS:+AnsiString):+TPCharEx%3B+inline%3B%0A++++class+operator+:%3D(constref+LHS:+ShortString):+TPCharEx%3B+inline%3B%0A++end%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Aprocedure+ImplicitConversionTest%3B+inline%3B%0A%0Aimplementation%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+AnsiString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0A++++P+:%3D+@LHS%5B1%5D%3B%0A++++L+:%3D+Length(LHS)%3B%0A++end%3B%0Aend%3B%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+ShortString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0A++++P+:%3D+@LHS%5B1%5D%3B%0A++++L+:%3D+Ord(LHS%5B0%5D)%3B%0A++end%3B%0Aend%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Avar+Old,+New:+PChar%3B%0Abegin%0A++SetLength(Result,+P.L+%2B+1)%3B%0A++Old+:%3D+P.P+%2B+P.L%3B%0A++New+:%3D+@Result%5B1%5D%3B%0A++while+Old+%3E%3D+P.P+do+begin%0A++++New%5E+:%3D+Old%5E%3B%0A++++Inc(New)%3B%0A++++Dec(Old)%3B%0A++end%3B%0Aend%3B%0A%0Aprocedure+ImplicitConversionTest%3B%0Abegin%0A++WriteLn(Reversed(!&#39;ABCD!&#39;))%3B%0Aend%3B%0A%0Aend.%0A&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;Pascal+source+%231&#39;,t:&#39;0&#39;)),k:54.64556642679632,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:compiler,i:(compiler:fpc304,filters:(b:&#39;0&#39;,binary:&#39;1&#39;,commentOnly:&#39;0&#39;,demangle:&#39;0&#39;,directives:&#39;0&#39;,execute:&#39;0&#39;,intel:&#39;0&#39;,libraryCode:&#39;1&#39;,trim:&#39;1&#39;),lang:pascal,libs:!(),options:&#39;-O3+-Ci-+-Cr-+-g-+-CX+-XXs&#39;,source:1),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;x86-64+fpc+3.0.4+(Editor+%231,+Compiler+%231)+Pascal&#39;,t:&#39;0&#39;)),k:44.015665176626996,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:output,i:(compiler:1,editor:1,wrap:&#39;1&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;%231+with+x86-64+fpc+3.0.4&#39;,t:&#39;0&#39;)),k:1.3387683965766675,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;)),l:&#39;2&#39;,n:&#39;0&#39;,o:&#39;&#39;,t:&#39;0&#39;)),version:4">Here's an example.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ben Grasset
On Wed, Jun 26, 2019 at 3:28 PM Ben Grasset <[hidden email]> wrote:
I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. <a href="https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,lang:pascal,source:&#39;unit+output%3B%0A%0A%7B$mode+ObjFPC%7D%7B$H%2B%7D%0A%7B$modeswitch+AdvancedRecords%7D%0A%7B$ImplicitExceptions+Off%7D%0A%0Ainterface%0A%0Atype+%0A++TPCharEx+%3D+record%0A++++P:+PChar%3B%0A++++L:+SizeInt%3B%0A++++class+operator+:%3D(constref+LHS:+AnsiString):+TPCharEx%3B+inline%3B%0A++++class+operator+:%3D(constref+LHS:+ShortString):+TPCharEx%3B+inline%3B%0A++end%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Aprocedure+ImplicitConversionTest%3B+inline%3B%0A%0Aimplementation%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+AnsiString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0A++++P+:%3D+@LHS%5B1%5D%3B%0A++++L+:%3D+Length(LHS)%3B%0A++end%3B%0Aend%3B%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+ShortString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0A++++P+:%3D+@LHS%5B1%5D%3B%0A++++L+:%3D+Ord(LHS%5B0%5D)%3B%0A++end%3B%0Aend%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Avar+Old,+New:+PChar%3B%0Abegin%0A++SetLength(Result,+P.L+%2B+1)%3B%0A++Old+:%3D+P.P+%2B+P.L%3B%0A++New+:%3D+@Result%5B1%5D%3B%0A++while+Old+%3E%3D+P.P+do+begin%0A++++New%5E+:%3D+Old%5E%3B%0A++++Inc(New)%3B%0A++++Dec(Old)%3B%0A++end%3B%0Aend%3B%0A%0Aprocedure+ImplicitConversionTest%3B%0Abegin%0A++WriteLn(Reversed(!&#39;ABCD!&#39;))%3B%0Aend%3B%0A%0Aend.%0A&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;Pascal+source+%231&#39;,t:&#39;0&#39;)),k:54.64556642679632,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:compiler,i:(compiler:fpc304,filters:(b:&#39;0&#39;,binary:&#39;1&#39;,commentOnly:&#39;0&#39;,demangle:&#39;0&#39;,directives:&#39;0&#39;,execute:&#39;0&#39;,intel:&#39;0&#39;,libraryCode:&#39;1&#39;,trim:&#39;1&#39;),lang:pascal,libs:!(),options:&#39;-O3+-Ci-+-Cr-+-g-+-CX+-XXs&#39;,source:1),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;x86-64+fpc+3.0.4+(Editor+%231,+Compiler+%231)+Pascal&#39;,t:&#39;0&#39;)),k:44.015665176626996,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:output,i:(compiler:1,editor:1,wrap:&#39;1&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;%231+with+x86-64+fpc+3.0.4&#39;,t:&#39;0&#39;)),k:1.3387683965766675,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;)),l:&#39;2&#39;,n:&#39;0&#39;,o:&#39;&#39;,t:&#39;0&#39;)),version:4" target="_blank">Here's an example.

Messed up the "Reversed" function a little bit in that example. <a href="https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,lang:pascal,source:&#39;unit+output%3B%0A%0A%7B$mode+ObjFPC%7D%7B$H%2B%7D%0A%7B$modeswitch+AdvancedRecords%7D%0A%7B$ImplicitExceptions+Off%7D%0A%0Ainterface%0A%0Atype+%0A++TPCharEx+%3D+record%0A++++P:+PChar%3B%0A++++L:+SizeInt%3B%0A++++class+operator+:%3D(constref+LHS:+AnsiString):+TPCharEx%3B+inline%3B%0A++++class+operator+:%3D(constref+LHS:+ShortString):+TPCharEx%3B+inline%3B%0A++end%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Aprocedure+ImplicitConversionTest%3B+inline%3B%0A%0Aimplementation%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+AnsiString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0A++++P+:%3D+@LHS%5B1%5D%3B%0A++++L+:%3D+Length(LHS)%3B%0A++end%3B%0Aend%3B%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+ShortString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0A++++P+:%3D+@LHS%5B1%5D%3B%0A++++L+:%3D+Ord(LHS%5B0%5D)%3B%0A++end%3B%0Aend%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Avar+Old,+New:+PChar%3B%0Abegin%0A++SetLength(Result,+P.L)%3B%0A++Old+:%3D+P.P+%2B+P.L+-+1%3B%0A++New+:%3D+@Result%5B1%5D%3B%0A++while+Old+%3E%3D+P.P+do+begin%0A++++New%5E+:%3D+Old%5E%3B%0A++++Inc(New)%3B%0A++++Dec(Old)%3B%0A++end%3B%0Aend%3B%0A%0Aprocedure+ImplicitConversionTest%3B%0Abegin%0A++WriteLn(Reversed(!&#39;ABCD!&#39;))%3B%0Aend%3B%0A%0Aend.%0A&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;Pascal+source+%231&#39;,t:&#39;0&#39;)),k:54.64556642679632,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:compiler,i:(compiler:fpc304,filters:(b:&#39;0&#39;,binary:&#39;1&#39;,commentOnly:&#39;0&#39;,demangle:&#39;0&#39;,directives:&#39;0&#39;,execute:&#39;0&#39;,intel:&#39;0&#39;,libraryCode:&#39;1&#39;,trim:&#39;1&#39;),lang:pascal,libs:!(),options:&#39;-O3+-Ci-+-Cr-+-g-+-CX+-XXs&#39;,source:1),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;x86-64+fpc+3.0.4+(Editor+%231,+Compiler+%231)+Pascal&#39;,t:&#39;0&#39;)),k:44.015665176626996,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;),(g:!((h:output,i:(compiler:1,editor:1,wrap:&#39;1&#39;),l:&#39;5&#39;,n:&#39;0&#39;,o:&#39;%231+with+x86-64+fpc+3.0.4&#39;,t:&#39;0&#39;)),k:1.3387683965766675,l:&#39;4&#39;,n:&#39;0&#39;,o:&#39;&#39;,s:0,t:&#39;0&#39;)),l:&#39;2&#39;,n:&#39;0&#39;,o:&#39;&#39;,t:&#39;0&#39;)),version:4">Fixed version. 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ryan Joseph-2
In reply to this post by Ben Grasset


> On Jun 26, 2019, at 3:28 PM, Ben Grasset <[hidden email]> wrote:
>
> I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. Here's an example.

Yes indeed. FPC already has an overwhelming amount of string types. As I said though a SetCapacity option for growing would be nice (for dynamic arrays also) because += is such a common operation. As it stands I often don’t use dynamic arrays (and now ansistring) because of growing limitations, which is a shame really.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ben Grasset
On Wed, Jun 26, 2019 at 5:36 PM Ryan Joseph <[hidden email]> wrote:
Yes indeed. FPC already has an overwhelming amount of string types. As I said though a SetCapacity option for growing would be nice (for dynamic arrays also) because += is such a common operation. As it stands I often don’t use dynamic arrays (and now ansistring) because of growing limitations, which is a shame really.

Well, I think the idea is that stuff like capacity is what you'd have / do have in actual containers built *around* strings and / or dynamic arrays, as they're both just built in primitives.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Free Pascal - General mailing list
In reply to this post by Ryan Joseph-2
Am 26.06.2019 um 23:36 schrieb Ryan Joseph:
>
>> On Jun 26, 2019, at 3:28 PM, Ben Grasset <[hidden email]> wrote:
>>
>> I think Ryan probably meant his own custom types. And certainly, you can do some interesting stuff with operator overloading that mostly avoids the normal AnsiString overhead. Here's an example.
> Yes indeed. FPC already has an overwhelming amount of string types. As I said though a SetCapacity option for growing would be nice (for dynamic arrays also) because += is such a common operation. As it stands I often don’t use dynamic arrays (and now ansistring) because of growing limitations, which is a shame really.
No. That would mean an additional entry in the metadata of strings and
arrays and those are already big enough in my opinion compared to the
data they're handling.
If one needs capacity based handling for these types then one should use
helper types.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Free Pascal - General mailing list
Am 27.06.2019 um 07:10 schrieb Sven Barth:

> Am 26.06.2019 um 23:36 schrieb Ryan Joseph:
>>
>>> On Jun 26, 2019, at 3:28 PM, Ben Grasset <[hidden email]> wrote:
>>>
>>> I think Ryan probably meant his own custom types. And certainly, you
>>> can do some interesting stuff with operator overloading that mostly
>>> avoids the normal AnsiString overhead. Here's an example.
>> Yes indeed. FPC already has an overwhelming amount of string types.
>> As I said though a SetCapacity option for growing would be nice (for
>> dynamic arrays also) because += is such a common operation. As it
>> stands I often don’t use dynamic arrays (and now ansistring) because
>> of growing limitations, which is a shame really.
> No. That would mean an additional entry in the metadata of strings and
> arrays and those are already big enough in my opinion compared to the
> data they're handling.
> If one needs capacity based handling for these types then one should
> use helper types.
Note: with which I mean types like TStringBuilder, not type helpers.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Martok
In reply to this post by Ryan Joseph-2
> Yes indeed. FPC already has an overwhelming amount of string types. As I said though a SetCapacity option for growing would be nice (for dynamic arrays also) because += is such a common operation. As it stands I often don’t use dynamic arrays (and now ansistring) because of growing limitations, which is a shame really.

Just chiming in: this should be handled by the memory manager.
"A chunk of memory gets grown repeatedly" is actually a fairly common workload,
not just for arrays, but also things like MemoryStreams or List classes.

So, I would expect (and FastMM has codepaths for that), that repeated
reallocations cause some form of "over-allocating" growth and most of the
individual "+1" reallocs will be essentially no-ops.

--
Regards,
Martok

Ceterum censeo b32079 esse sanandam.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Ryan Joseph-2


> On Jun 28, 2019, at 3:40 PM, Martok <[hidden email]> wrote:
>
> So, I would expect (and FastMM has codepaths for that), that repeated
> reallocations cause some form of "over-allocating" growth and most of the
> individual "+1" reallocs will be essentially no-ops.

Interesting. How could we test this to see if it’s true?

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: String conversions

Zoë Peterson
On 6/28/2019 3:07 PM, Ryan Joseph wrote:
>> On Jun 28, 2019, at 3:40 PM, Martok <[hidden email]> wrote:
>> So, I would expect (and FastMM has codepaths for that), that repeated
>> reallocations cause some form of "over-allocating" growth and most of the
>> individual "+1" reallocs will be essentially no-ops.
>
> Interesting. How could we test this to see if it’s true?

 From FastMM4's readme:

https://github.com/pleriche/FastMM4/blob/master/README.md

"Intelligent reallocations. Avoids slow memory move operations through
not performing unneccesary downsizes and by having a minimum percentage
block size growth factor when an in-place block upsize is not possible."

Allocations within certain ranges are all lumped together based on fixed
block sizes (e.g., 15-24 bytes allocations are all rounded up to 24
bytes).  It both reduces fragmentation and helps with resize performance
(there is other resize-specific logic as well).

String allocations and performance factored heavily into the
benchmarking for the FastCode competition that lead to FastMM4.  You
should do your own benchmarking vs the system allocator though, to see
if it provides an improvement, especially if you're doing extensive
multithreading.  We've been using FastMM with FPC on macOS and Linux for
about 4 years now and are very happy with it.

--
Zoë Peterson
Scooter Software

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal