[Qt-creator] Couple of questions about the design of Qt Creator

Eike Ziller Eike.Ziller at qt.io
Mon Sep 11 10:18:16 CEST 2017


> On Sep 11, 2017, at 10:13, Elvis Stansvik <elvstone at gmail.com> wrote:
> 
> 2017-09-10 13:58 GMT+02:00 André Pönitz <apoenitz at t-online.de>:
>> 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.

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
> Qt-creator at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator

-- 
Eike Ziller
Principal Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.ziller at qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



More information about the Qt-creator mailing list