...where the latter are reportedly expensive. Both
<https://gerrit.libreoffice.org/#/c/75162/> "tdf#121740 related, cache external
mapping in cppu::loadExternal" and <https://gerrit.libreoffice.org/#/c/82261/>
"tdf#121740 add cache to win osl_getModuleURLFromAddress" attempted to reduce
the costs observed when loading one specific document by introducing caches
below cppu::detail::loadModule's call to osl::Module::loadRelative.
On the other hand, this change reduces the number of calls to
osl_getModuleURLFromAddress by computing the base URI in
cppu::detail::loadModule only once. For my local Linux --enable-dbgutil build,
for `instdir/program/soffice '109340 class14.ppt'` and then exiting LO again
(with the document attached at
<https://bugs.documentfoundation.org/show_bug.cgi?id=121740#c0>), this reduces
the number of calls to osl_getModuleURLFromAddress from 3775 to 22.
(Many of those calls originated from cppu::getCaughtException or
cppu::throwException, as in
osl_getModuleURLFromAddress
osl_getModuleURLFromFunctionAddress
osl::Module::getUrlFromAddress
osl_loadModuleRelative
osl::Module::loadRelative
cppu::detail::loadModule
cppu::loadModule
cppu::loadExternalMapping
uno_getMapping
com::sun::star::uno::Mapping::Mapping
cppu::throwException
.)
Unfortunately, this needs to duplicate functionality from osl_loadModuleRelative
(sal/osl/all/loadmodulerelative.cxx) somewhat, as the stable SAL interface only
offers functionality to load relative to a given function, not relative to a
given base URI. (And extending the stable SAL interface for this one use is not
worth the maintenance costs.)
Change-Id: Ib58814136d11c67d1419b0224d12e30bb710e613
Reviewed-on: https://gerrit.libreoffice.org/82290
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
look for OUStringBuffer append sequences that can be turned
into creating an OUString with + operations
Change-Id: Ica840dc096000307b4a105fb4d9ec7588a15ade6
Reviewed-on: https://gerrit.libreoffice.org/80809
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Found with bin/find-unneeded-includes
Only removal proposals are dealt with here.
Change-Id: Ia1b2f0a9c99acc7ac538f3b41c1b6757d414db35
Reviewed-on: https://gerrit.libreoffice.org/66970
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
still leaks the handle of course, but c++izes the code and hides
the leak from coverity as a side-effect
Change-Id: Ieaab1545a98da1d699df93d020f0cb452ddf2516
Convert code like:
aStrBuf.appendAscii( RTL_CONSTASCII_STRINGPARAM( "ln(x)" ));
to:
aStrBuf.append( "ln(x)" );
which compiles down to the same code.
Change-Id: I24c7cb45ceb32fd7cd6ec7ed203c2a5d746f1c5c
There are basicically two classes of cases:
1) Where the code is for obscure historical reasons or what I see as
misguided "optimization" split into a more libraries than necessary,
and these then are loaded at run-time. Instead, just use direct
linking.
2) Where dynamic loading is part of the functionality offered to some
upper (scripting etc) layer, or where some system-specific non-LO
library is loaded dynamically, as it is not necessarily present on
end-user machines. Can't have such in the DISABLE_DYNLOADING case.
Change-Id: I9eceac5fb635245def2f4f3320821447bb7cd8c0
2007/06/26 13:37:45 sb 1.1.2.2: #i75466# Use new osl_loadModuleRelative to locate loaded libs next to calling lib.
2007/06/20 12:49:40 sb 1.1.2.1: #i75466# Unlike Solaris and Linux, Mac OS X dlopen does not search for file next to the library calling dlopen if file does not contain slashes (you have to prefix file with "@loader_path/" for that to work on Mac OS X); refactored accordingly.
Gabor Kelemen