3f768cddd2
Once you install an extension that adds its own protocol handlers (e.g. <https://github.com/niocs/ProtocolHandlerExtension>), DispatchProvider re-creates this protocol handler every time the custom menu gets opened or a command gets dispatched. This allows the dispatch provider to avoid managing the lifecycle of those protocol handler instances, but in case the constructor of those handlers is expensive, this leads to performance problems. Introduce a map of handler instances in DispatchProvider to avoid unnecessary re-creation and re-initialization: these instances get the same XFrame anyway (the DispatchProvider is owned by the frame), so this is meant to be safe. No testcase for this -- the problem is only visible if you have an UNO service registered in the global UNO service registry, but by the time our cppunit tests run, that is already a fixed list, so this would be hard to test from code. Change-Id: I6d69906a795a2d5a67706002d635b6cb3091b856 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133706 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins |
||
---|---|---|
.. | ||
closedispatcher.hxx | ||
dispatchinformationprovider.hxx | ||
dispatchprovider.hxx | ||
interceptionhelper.hxx | ||
mailtodispatcher.hxx | ||
oxt_handler.hxx | ||
popupmenudispatcher.hxx | ||
servicehandler.hxx | ||
startmoduledispatcher.hxx | ||
systemexec.hxx |