Re: String Buffer

[Vadim Godunko <vgodunko@gmail.com>]

On Thursday, December 2, 2021 at 9:17:38 PM UTC+3, kevc...@gmail.com wrote:
> In this thread bounded and unbounded get quite a bashing. 
> 
> "https://groups.google.com/g/comp.lang.ada/c/NINmFln-YS4/m/5De5DeUAAAAJ" 
> 
> I thought bounded looked useful but then I realised that it allocates the max immediately anyway. It may be useful in constrained environments but then I do not use Strings in constrained environments. 
> 
> Unbounded is said to be inefficient because it re-allocates. 
> 
> In Go they have strings.Builder. I assume that is what Text_Buffer is aimed to be. (Actually Go seems to have copied a lot from Ada such as AWS API, unless they both are similar to something else like JAVA). 
> 
> Is Text_Buffer usable today with GCC 11? 
> 
> strings.Builder in Go behaves similarly to unbounded in that it doubles the allocation as required but it only returns a string when needed and does not have string operations. You can Grow the builder to avoid re-allocations. 
> 
> "https://pkg.go.dev/strings#Builder" 
> 
> If possible without breaking all of the string functions (length and separate capacity) and Unbounded Strings had a Grow function, then wouldn't that relieve the efficiency issue? 
> 
> In any case avoiding unbounded strings is almost certainly in the realm of premature optimisation most of the alleged 10% of the time that it useful, but it would be nice to know of and use something akin to strings.Builder, preferably from the standard library, if it is available?

For VSS.Strings.Virtual_String we used two kinds of optimization:

1. Short strings are stored without any memory allocation. It saves a lot of time. This is not very visible in multithread applications due to runtime cost of controlled objects; however it is very visible on manycore due to less amount of involved atomic operations.  How "short" string should be depends from underlying encoding, content and machine architecture, on modern 64bit systems when UTF-8 encoding is used it is 17 ASCII characters, or 8 Cyrillic characters, or 4 math characters. In context of Ada Language Server most of cases are such small strings.

2. It is possible to set capacity for the particular string object. Memory will be reallocated on next modification operation of the string object. This may be useful for large strings, when approximate size of the string is known and allows to save few allocate/move memory cycles on append. I don't know any real use cases of this feature right now.