https://bugs.documentfoundation.org/show_bug.cgi?id=147104
Bug ID: 147104
Summary: Idea: use OUStringBuffer instead of OUString in
SbxValues
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: enhancement
Priority: medium
Component: BASIC
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: mikekagan...@hotmail.com
CC: andreas.heini...@yahoo.de
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.
--
You are receiving this mail because:
You are the assignee for the bug.
