LibreOffice's base string classes (OString / OUString) are designed to be wrappers around immutable ref-counted rtl_uString buffers. That allows to (aim to) minimize memory usage, but requires reallocation at every modifying operation on the strings.

E.g.:

  OUString s;
  for (int i = 0; i < 10; ++i)
    s += OUString::number(i) + ";"

This would re-allocate the string 10 times (so it will use ten different buffers, copy already created part ten times, etc.), instead of using the same buffer as much as possible, with a doubling the buffer when necessary strategy.

This becomes a problem in Basic, which is a general-purpose programming language. It uses OUString as internal implementation of its string type; and hence, code like

  s=""
  For i=1 To 100000
    s=s & CStr(i)
  next i

would take very long.

There's a OUStringBuffer class in LO, which is a wrapper around the same rtl_uString buffer, but designed to be mutable, with normal buffer growth strategy. The idea is to try to replace use of OUString with OUStringBuffer in SbxValues, and this way, make Basic more generic, without this LibreOffice-specific way of handling strings.

Since SbxBase is ref-counted itself, assigning string variables in Basic would still not create excessive memory use; only modifying operations would trigger normal copy-on-write behavior.

This might be not doable (needs investigation), or difficult in the end.