Hi Stephan, Thanks for the review ! Matus should start work on this shortly.
On Fri, 2013-10-11 at 17:20 +0200, Stephan Bergmann wrote: > DllComponentLoader is mostly dead by now, only comes into play during ... > Handling of the prefix feature is done entirely in > cppuhelper/source/servicemanger.cxx and cppu::loadSharedLibComponentFactory. Ah right my bad; as you say we should add this here: > To split into smaller, unconnected parts would mean to split existing > <component> XML entities into smaller ones, each with its own prefix That would suck IMHO :-) we have enough scattered files. > Or, as you detail below, go further and add more efficient support for > the "single-object-implementation" factory case. (Do you have any idea > whether this is worth it, given we have to continue supporting the other > case for extension-compatibility anyway?) Sure it's worth it given we're primarily looking for size savings for mobile; for the Linux case we get only marginal wins here I think. > Anyway, given that the current "prefix" feature should only be used by > internal code we have under full control (see recent discussion > elsewhere on this mailing list), should we go down that road, I'd prefer > to replace the existing "prefix" feature with something new (e.g., an > extension of the components XML schema that associates an individual > <implementation> rather than a <component> with a prefix attribute), > rather than keeping both. (Though we could support both for a > transition period while we incrementally update the existing code.) Yep - agreed; it's nice we're flexible here, just some inevitable transition period where we'd try the direct symbol approach, and then fallback to the old prefix'd factory function. > What would likely be more entertaining is to get rid of the > cppu::createSingleFactory layer of indirection. (As you come to in part > three. But note that there are service implementations that rather act > like singletons and always hand out the same object instance; that needs > to be taken care of.) Yes - hopefully that's easily done. Luckily it's all internal, was just chatting with Matus and considering the symbol could point to a C struct easily enough something like: extern "C" struct { const char *pImplementationName; ComponentInstantiation pCreateFunction const char *pServiceNames[]; } ComponentEntryPoint; And have some wrappers to help with converting the ComponentEntryPoint record into the results we want from the XServiceInfo methods (getSupportedServiceNames etc.) > An alternative is to extend the components XML schema to support lookup > of the factory function directly in the executable (say) rather than a > given dynamic library (e.g., by having a local="true" attribute rather > than a uri="..." one). Since the uri attributes are already inserted > into the .component XML files at build-time, it shouldn't be too hard to > combine that with a configurable list of components that end up directly > linked into the executable. Interesting idea. I'd like to see how this shakes out in a few iterations here I think. I agree that we're going to need something like: <component loader="com.sun.star.loader.SharedLibrary" prefix="svx" xmlns="http://openoffice.org/2010/uno-components"> - <implementation name="com.sun.star.comp.Draw.GraphicExporter"> + <implementation name="com.sun.star.comp.Draw.GraphicExporter" direct="true"> <service name="com.sun.star.drawing.GraphicExportFilter"/> </implementation> <implementation name="com.sun.star.comp.Svx.GraphicExportHelper"> <service name="com.sun.star.document.BinaryStreamResolver"/> <service name="com.sun.star.document.GraphicObjectResolver"/> </implementation> Incidentally - do we actually use the service information in anger ? ie. could we not populate / store the data required for the XServiceInfo interface from the services.rdb at run-time, rather than having it duplicated in the code ? or is there some benefit to that ? > In addition to having them stored as XML files that are parsed at start-up in > cppuhelper::ServiceManager::init, one could optionally have them > pre-compiled into some data structure that is accessible from > cppuhelper/source/servicemanager.cxx. In which case the data structures > for such local="true" components could directly contain function > pointers to the corresponding factories. Very true =) perhaps that would get rid of the whole native-code.cxx mess as well - centralizing it and making it fully generic - that would be nice. > > * Part three - faster component instantiation > > > > The wonderful work Noel has been doing around more beautiful > > ways to instantiate components should dove-tail with this nicely. ... > > Which should be much smaller and neater. > > Question is how much that "much" would actually be. (And one would have > to generate two variants of service/singleton C++ headers, an optimized > one for internal use and a traditional one for external use.) Well if we call directly into the method that instantiates the object, then LTO can potentially start to inline a lot of things and ignore a lot of exceptions that we know are not thrown etc. presumably it may have some benefits for a merged-libs case. Anyhow - thanks for the feedback - moving ahead here soon (I hope) on master. ATB, Michael. -- michael.me...@collabora.com <><, Pseudo Engineer, itinerant idiot _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice