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

[Elvis Stansvik]

2017-09-11 10:18 GMT+02:00 Eike Ziller <Eike.Ziller at qt.io>:
>
>> 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.

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
>> 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
>