[Gambas-user] Is the &= efficient?

[Cedron Dawg]

Hi Tobi,

"This implies that concatenation has to realloc and copy" is not necessarily true.  I wrote a string heap a long time ago which attempted to be efficient.  Shortening a string merely meant adjusting the pointer block, no news there.  In lengthening the string, the algorithm checked for room at the end.  If there was, it appended the data there.  When you were building a string, it was likely it was on top of the heap so there was lots of room.

When a allocation was asked for, the first gap large enough was used to reduce garbage collections.  Garbage collections were limited to compression until the gap got large enough for the requested string size.  Sometimes this meant a full garbage collection, but that is the default behavior for most string heaps.

I'll investigate this valgrind tool when I get a chance.  Right now, I have no pressing need, the program still runs in an eye blink.

Ced



----- Original Message -----
From: "Tobias Boege" <taboege at gmail.com>

A string in Gambas is a base pointer, an index into it and a length.
This implies that concatenation has to realloc and copy. (It also
means by contrast that operations like Mid$() are very cheap.)

You can observe this with a test program like this:

  Public Const Lipsum As String = ""
  "Lorem ipsum dolor sit amet, consetetur sadipscing elitr, "
  ' around 600 bytes of etc.

  Public Sub Main()
    Dim s As String

    If Args.Count < 2 Then Error.Raise("Need number of iterations")
    For i As Integer = 0 To CInt(Args[1])
      s &= Lipsum
    Next
  End

and valgrind:

  $ valgrind -- gbx3 -- 0 2>&1 | grep -o "total heap usage.*"
  total heap usage: 338 allocs, 338 frees, 75,382 bytes allocated
  $ valgrind -- gbx3 -- 10 2>&1 | grep -o "total heap usage.*"
  total heap usage: 348 allocs, 348 frees, 115,222 bytes allocated
  $ valgrind -- gbx3 -- 100 2>&1 | grep -o "total heap usage.*"
  total heap usage: 438 allocs, 438 frees, 3,134,134 bytes allocated
  $ valgrind -- gbx3 -- 1000 2>&1 | grep -o "total heap usage.*"
  total heap usage: 1,338 allocs, 1,338 frees, 296,614,134 bytes allocated

While the numbers of allocations line up perfectly with the Gambas
code that you see, you can guess from those samples regarding "bytes
allocated" that the cumulative memory usage grows almost quadratically
in the number of iterations, which may at least count as some evidence
for a plain realloc and copy.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----