https://bugs.freedesktop.org/show_bug.cgi?id=78479
--- Comment #4 from Michael Meeks <[email protected]> --- > 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 i18npool, and that some UNO services provided by i18npool are > either created afresh too often by client code (instead of > keeping references around) That is the 'caller is at fault' one off argument :-) > or should rather be singletons instead of services. But would be easier > to tell when seeing backtraces for those calls to osl_loadModuleRelative. The backtraces are in the callgrind file - but not in a pretty form - run in Kcachegrind and everything you need and more is there. My strong suspicion is that the UNO core could do better here - wrt. not going to osl_loadModuleRelative when we did that load / OS / symbol lookup just recently. Surely it is always possible to blame the caller for not working around performance issues underneath and there is a limit to how fast any one thing can be but ... ;-) In this case it seems that we could do better [ this is far from the first time I've seen performance problems of this sort ]. i18npool/source/breakiterator/breakiteratorImpl.cxx:sal_Int32 SAL_CALL BreakIteratorImpl::previousCharacters( const OUString& Text, sal_Int32 nStartPos, is near the root of the trace. #define LBI getLocaleSpecificBreakIterator(rLocale) ... return LBI->nextCharacters( Text, nStartPos, rLocale, nCharacterIteratorMode, nCount, nDone); the cost being in 'getLocaleSpecificBreakIterator': which already has some caching left/right: perhaps that caching doesn't work that well. The issue here is when you get a complex document with lots of different characters next to each other, or in the same paragraph / string - then performance goes to pot. Surely this is easier to fix in the infrastructure than by everyone having to wrap DIY caches around UNO service instantiation =) -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
