2017-09-11 10:18 GMT+02:00 Eike Ziller <[email protected]>: > >> On Sep 11, 2017, at 10:13, Elvis Stansvik <[email protected]> wrote: >> >> 2017-09-10 13:58 GMT+02:00 André Pönitz <[email protected]>: >>> On Sun, Sep 10, 2017 at 11:31:58AM +0200, Elvis Stansvik wrote: >>>> As soon as I hit send, I realized I have a third question: >>>> >>>> 3. Communication Between Plugins: >>>> >>>> There seems to be two main mechanisms through which plugins >>>> communicate: Either objects that implement shared interfaces are added >>>> to the plugin manager object pool and picked up by downstream or >>>> upstream plugins (in the top-down or bottom-up phase of plugin >>>> initialization, respectively), or a singleton instance is acquired and >>>> calls made on it. >>>> >>>> Is the former approach used when dependants provide functionality to >>>> their dependees (which are unknown), and the latter approach used when >>>> dependees use their dependants (which are known)? Is that the deciding >>>> factor? >>> >>> I am not sure there is a strict deciding factor or even policy. >>> There are certainly historical and personal aspects involved. >>> >>> The object pool has some systematic quadratic behaviour built-in, >> >> The quadratic behavior, do you mean when a plugin is destroyed and it >> calls removeObject(..) for each of it's auto-released object in >> d->addedObjectsInReverseOrder (which could possibly be many)?. Or are >> there other inherently quadratic operations on the pool? > > Whenever a lookup is done with PluginManager::getObject, this potentially > goes through all objects in the pool and checks with qobject_cast, whether > this object should be returned. PluginManager::getObjects always has to go > through the whole list of objects in the pool and cast. > So each object in the pool affects the performance of each call to the > getObject(s) methods.
Ah right, in that sense it's quadratic. Elvis > > Br, Eike > >> Elvis >> >>> so even if it is still ok, it won't scale arbitrarily. So I am >>> trying to reduce it's use in well-known cases where one side >>> depends on the other anyway, e.g. replace various factories >>> hat so far ended up in the pool with explicit registration of >>> their upstream users, and only use the pool where it's flexibility >>> is really needed. >>> >>> Andre' >> _______________________________________________ >> Qt-creator mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/qt-creator > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > [email protected] > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
