Re: pre-init / strings ...

Hi Stephan,

On 08/12/17 09:26, Stephan Bergmann wrote:
> If the issue is mostly with rtl_uString that originated from
> (implicitly) converting a string literal in the source code into an
> rtl::OUString instance (rather than rtl::OUString instances that have
> actually been computed from other values during the pre-initialization
> phase, and survive past that phase):

        Good question; certainly some proportion of them are - but that's hard
to count really. Another big slew of them come from the configuration
data, filter data, and so on.

> I think that with
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0424r2.pdf>
> "String literals as non-type template parameters" potentially making it
> into C++20 (and potentially being available in Clang or GCC even before;
> it already is, in a form almost usable for our needs), we will be able
> to create such rtl_uString from string literals in the source code
> during compilation, placing them into read-only data segments.

        Yep; should be more efficient for both desktop and server.

> So, it would be interesting to know whether the issue indeed is mostly
> with such rtl_uString instances, so that the mechanism I outlined above
> would be going to sufficiently solve your issue.

        Yep; interesting, but - of course, us switching to a C++20 baseline is
(presumably) at least 3 years out, and more likely 5 ;-)

        So I think we need to get this in in this form now (which,
interestingly gives a reason to survive for the mhu allocator in master
for a little longer ;-).

> this would need to be PRIVATE_1.5 (we're already at PRIVATE_1.4 for
> LibreOffice 6.0)

        Good point; any other significant concerns ? modulo un-necessary
'extern "C"' ness etc. otherwise - I'll massage it into better shape,
and push it to gerrit vs. master.

        Thoughts on making rtl_arena_foreach public ? I suspect that other
types will be discovered higher in the stack that would also benefit
from similar treatment. I'm spending some chunks of time reading
annoyingly regular hexdumps of lots of un-shared memory =)

        ATB,

                Michael.

-- 
michael.meeks@collabora.com <><, Pseudo Engineer, itinerant idiot