https://bugs.freedesktop.org/show_bug.cgi?id=78479
Michael Meeks michael.me...@collabora.com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=78479
--- Comment #1 from Michael Meeks michael.me...@collabora.com ---
Created attachment 98739
-- https://bugs.freedesktop.org/attachment.cgi?id=98739action=edit
a photo of the issue =)
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=78479
--- Comment #2 from Stephan Bergmann sberg...@redhat.com ---
UNO does not unload any component libraries. I assume the calls to
osl_loadModuleRelative you are observing are coming from code in i18npool, and
that some UNO services provided by
https://bugs.freedesktop.org/show_bug.cgi?id=78479
--- Comment #3 from Stephan Bergmann sberg...@redhat.com ---
Indeed, wading through
http://users.freedesktop.org/~michael/callgrind-asian-entry-at-34ae7b16d.txt.gz,
SwEditShell:Insert2 -
SwEditShell:EndAllAction -
SwCrsrShell::EndAction -
https://bugs.freedesktop.org/show_bug.cgi?id=78479
--- Comment #4 from Michael Meeks michael.me...@collabora.com ---
UNO does not unload any component libraries.
Ah - fair enough; glad that's so.
I assume the calls to osl_loadModuleRelative you are observing are coming
from code in
https://bugs.freedesktop.org/show_bug.cgi?id=78479
--- Comment #5 from Stephan Bergmann sberg...@redhat.com ---
(In reply to comment #4)
Surely this is easier to fix in the infrastructure than by everyone having
to wrap DIY caches around UNO service instantiation =)
No. There are legitimate
https://bugs.freedesktop.org/show_bug.cgi?id=78479
--- Comment #6 from Michael Meeks michael.me...@collabora.com ---
Hah :-) it seems that in fact that at least one big chunk of the cost is not
UNO loading anything but some internal dlopen in the breakiterator:
xdictionary::xdictionary(const
