Apache OpenOffice (AOO) Bugzilla – Issue 51181
startup performance issue ... (with Gnome VFS)
Last modified: 2006-12-06 14:14:17 UTC
If you have the Gnome VFS UCP installed - which tries to handle all otherwise unhandled URIs - then unfortunately without the appended patch, OO.o ensures that the VFS is loaded, initialized - adding a number of libraries to the search path (thus slowing down all subsequent relocations) adding a number of pointless seeks etc. to startup. And all for this URI type that is (AFAIR) never used outside of the (now defunct?) StarPortal product (?). --- ucbhelper/source/client/fileidentifierconverter.cxx +++ ucbhelper/source/client/fileidentifierconverter.cxx @@ -107,7 +107,7 @@ OSL_ASSERT(rManager.is()); static sal_Char const * const aBaseURLs[] - = { "file:///", "vnd.sun.star.wfs:///" }; + = { "file:///" };//, "vnd.sun.star.wfs:///" }; sal_Int32 nMaxLocality = -1; rtl::OUString aMaxBaseURL; for (int i = 0; i < sizeof aBaseURLs / sizeof (sal_Char const *); ++i)
Ah - Matthias - I forgot; this is a prime example of my desire for a (permanant) 'ASSERT_NOT_DURING_STARTUP' type invocation that can stop this sort of thing slipping back into the code as/when some newfangled / new URI lookup scheme happens :-)
#0 0x43df7874 in gnome_vfs_init () from /opt/gnome/lib/libgnomevfs-2.so.0 #1 0x43db4c90 in component_getFactory (pImplName=0x8282fc8 "com.sun.star.comp.GnomeVFSContentProvider", pServiceManager=0x80d48b8, pRegistryKey=0x827e56c) at /opt/OpenOffice/src680-m110/ucb/source/ucp/gvfs/provider.cxx:249 #2 0x40d73669 in cppu::loadSharedLibComponentFactory () from ./libuno_cppuhelpergcc3.so.3 #3 0x427374b7 in stoc_loader::DllComponentLoader::activate () from /opt/OOInstall/program/shlibloader.uno.so #4 0x40d67e63 in cppu::createStandardClassWithSequence () from ./libuno_cppuhelpergcc3.so.3 #5 0x40d6702a in cppu::createStandardClassWithSequence () from ./libuno_cppuhelpergcc3.so.3 #6 0x40d65856 in cppu::createStandardClassWithSequence () from ./libuno_cppuhelpergcc3.so.3 #7 0x40d664b7 in cppu::createStandardClassWithSequence () from ./libuno_cppuhelpergcc3.so.3 #8 0x4271fd36 in stoc_smgr::OServiceManager::createInstanceWithContext () from /opt/OOInstall/program/servicemgr.uno.so #9 0x427204a5 in stoc_smgr::OServiceManager::createInstance () from /opt/OOInstall/program/servicemgr.uno.so #10 0x43d13e4a in UcbContentProviderProxy::getContentProvider (this=0x8154908) at /opt/OpenOffice/src680-m110/ucb/source/core/provprox.cxx:391 #11 0x43d132c9 in UcbContentProviderProxy::queryInterface (this=0x8154908, rType=@0x40d063c8) at /opt/OpenOffice/src680-m110/ucb/source/core/provprox.cxx:204 #12 0x40182344 in com::sun::star::uno::BaseReference::iquery () from ./libvcl680li.so #13 0x40cc8def in com::sun::star::uno::Reference<com::sun::star::ucb::XFileIdentifierConverter>::iquery (pInterface=0x8154924) at Reference.hxx:108 #14 0x40cc8c6c in Reference (this=0xbfffe7d0, rRef=@0xbfffe7c0) at Reference.hxx:181 #15 0x40cc88a3 in ucb::getLocalFileURL (rManager=@0xbfffe900) at /opt/OpenOffice/src680-m110/ucbhelper/source/client/fileidentifierconverter.cxx:118 #16 0x40a43a52 in utl::LocalFileHelper::ConvertURLToPhysicalName (rName=@0xbfffe970, rReturn=@0xbfffe990) at /opt/OpenOffice/src680-m110/unotools/source/ucbhelper/localfilehelper.cxx:189 #17 0x0807bc1f in desktop::Desktop::CreateTemporaryDirectory () #18 0x0807b335 in desktop::Desktop::RegisterServices () #19 0x0806d1c5 in desktop::Desktop::Main () #20 0x4017a893 in SVMain () from ./libvcl680li.so #21 0x08068bb1 in sal_main () #22 0x08068b4c in main ()
Hi Michael, Mathias, Indeed, the gnome-vfs ucp should not be loaded during normal startup. Mathias, can you please comment on this, i.e. removing 'vnd.sun.star.wfs' URIs, and if it can safely be done reassign to the appropriate engineer? Alternatively, I'm sure Michael can do the work on one of his child workspaces :-) Thanks, Matthias
Thanks for pointing us to the problem, Michael. The patch is OK, but Stephan Bergmann thinks that meanwhile most of the code in this function is superfluous, so I would like to let him decide wether we just apply the patch or remove even more code. IMHO a target "2.0" is appropriate because at least the patch is not a large risk.
accepted
Fixed. See issue 51272 for generally cleaning up this code.
sb->atr: Please verify that this caused no general regressions. re-open issue and reassign to atr@openoffice.org
reassign to atr@openoffice.org
reset resolution to FIXED
Adding dependency to issue 20269 (startup performance)...
ATR: task verified in cws sb33, fixed.
ATR: checked again in masterbuilkd m120, fixed.
In 2.0.4 ucpgvfs1.uno.so is again being loaded at startup, but now through a slightly different code path: #0 0xb34b7ee6 in gnome_vfs_init () from /opt/gnome/lib/libgnomevfs-2.so.0 #1 0xb3525c45 in component_getFactory (pImplName=0x81530c8 "com.sun.star.comp.GnomeVFSContentProvider", pServiceManager=0x80c9928) at /home/tml/ooo-build/2.0.4.9/build/OOO_2_0_4/ucb/source/ucp/gvfs/provider.cxx:223 #2 0xb76b46f8 in cppu::loadSharedLibComponentFactory () from /opt/local/lib/ooo-2.0.4.9/program/libuno_cppuhelpergcc3.so.3 #3 0xb5d83f73 in stoc_loader::DllComponentLoader::activate () from /opt/local/lib/ooo-2.0.4.9/program/shlibloader.uno.so #4 0xb76ad169 in cppu::ORegistryFactoryHelper::createModuleFactory () from /opt/local/lib/ooo-2.0.4.9/program/libuno_cppuhelpergcc3.so.3 #5 0xb76ad5b6 in cppu::ORegistryFactoryHelper::createInstanceEveryTime () from /opt/local/lib/ooo-2.0.4.9/program/libuno_cppuhelpergcc3.so.3 #6 0xb76acab1 in cppu::OSingleFactoryHelper::createInstanceWithContext () from /opt/local/lib/ooo-2.0.4.9/program/libuno_cppuhelpergcc3.so.3 #7 0xb76acb69 in cppu::OFactoryComponentHelper::createInstanceWithContext () from /opt/local/lib/ooo-2.0.4.9/program/libuno_cppuhelpergcc3.so.3 #8 0xb5c8e86e in stoc_smgr::OServiceManager::createInstanceWithContext () from /opt/local/lib/ooo-2.0.4.9/program/servicemgr.uno.so #9 0xb5c8d655 in stoc_smgr::OServiceManager::createInstance () from /opt/local/lib/ooo-2.0.4.9/program/servicemgr.uno.so #10 0x08075b51 in configureUcb (bServer=false, rPortalConnect=@0xbff8e0a8) at /home/tml/ooo-build/2.0.4.9/build/OOO_2_0_4/desktop/source/app/appinit.cxx:240 #11 0x08076154 in desktop::Desktop::RegisterServices (this=0xbff8e33c, xSMgr=@0xbff8e230) at /home/tml/ooo-build/2.0.4.9/build/OOO_2_0_4/desktop/source/app/appinit.cxx:349 #12 0x0806bb1c in desktop::Desktop::Main () #13 0xb7d942c0 in ImplSVMain () from /opt/local/lib/ooo-2.0.4.9/program/libvcl680li.so #14 0xb7d943b5 in SVMain () from /opt/local/lib/ooo-2.0.4.9/program/libvcl680li.so #15 0x08064931 in sal_main () #16 0xb6eb987c in __libc_start_main () from /lib/libc.so.6 #17 0x08064861 in _start () Now it's the code in desktop/source/app/appinit.cxx:configureUcb() that causes this to happen. Previously the GnomeVFS UCP was instantiated through the proxy ucp factory, but that apparently caused some other problems, so that code if bypassed with #if 0 and now it is instantiated straight away. A simpleish (in this case, with just three source files) solution to the slowness introduced by loading libgnomevfs with all its dependencies is to remove the direct calls to libgnomevfs functions from ucpgvfs, and instead load it dynamically with dlopen() only when actually needed, and call the libgnomevfs functions through function pointers. On Solaris I guess lazy loading of shared objects would do this automatically (but is it used for OOo?), but no lazy or delayed loading of dependent shared objects in Linux, as far as I know.