QList <->QVector

[Andi Clemens]

Hi,

in STL, we use std::vector most of the time, but in Qt programs we tend to  
use QList instead of QVector, which seems to be a performance issue,
see  
http://marcmutz.wordpress.com/2010/07/29/sneak-preview-qlist-considered-harmful/ 
.

Maybe we should consider changing QList to QVector in digiKam's code? With  
the patch in the above link Qt will throw a warning when an inefficient  
type is used in the QList container.

Andi


--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> Maybe we should consider changing QList to QVector in digiKam's code? With
> the patch in the above link Qt will throw a warning when an inefficient
> type is used in the QList container.

QList is much more convenient IMO. Most importantly, Qt API usually takes
QLists and not QVectors, and a conversion may render any won time to a loss.

I suggest therefore only to think of conversion if profiling proofs that QList
usage is a problem (*)

There are places in digikam code where this has already been done: Most
importantly, in DigikamKCategorizedView, and in ImageFilterModel

(*) For our needs, QList will get problematic if the stored object is larger
than a pointer, and or not movable. In profiling, the construction and
destruction of the object will then become noticeable. Unfortunately, two
important and extensively used classes are problematic in this regard:
QModelIndex and QVariant. But Qt API uses QList everywhere for those, so
QVector is often not an option.

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Andi,

Before to patch in this way, i sugest to way 2.1.0 release planed next sunday.

On my computer, i currently review 2 big patches :

https://bugs.kde.org/show_bug.cgi?id=155374

.. which will be complex to adapt because they touch a lots of parts
in digiKam...

Gilles

2011/8/28 Marcel Wiesweg <[hidden email]>:

>
>
>> Maybe we should consider changing QList to QVector in digiKam's code? With
>> the patch in the above link Qt will throw a warning when an inefficient
>> type is used in the QList container.
>
> QList is much more convenient IMO. Most importantly, Qt API usually takes
> QLists and not QVectors, and a conversion may render any won time to a loss.
>
> I suggest therefore only to think of conversion if profiling proofs that QList
> usage is a problem (*)
>
> There are places in digikam code where this has already been done: Most
> importantly, in DigikamKCategorizedView, and in ImageFilterModel
>
> (*) For our needs, QList will get problematic if the stored object is larger
> than a pointer, and or not movable. In profiling, the construction and
> destruction of the object will then become noticeable. Unfortunately, two
> important and extensively used classes are problematic in this regard:
> QModelIndex and QVariant. But Qt API uses QList everywhere for those, so
> QVector is often not an option.
>
> Marcel
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Forget to said that i will apply patches just after 2.1.0 release.

Gilles

2011/8/28 Gilles Caulier <[hidden email]>:

> Andi,
>
> Before to patch in this way, i sugest to way 2.1.0 release planed next sunday.
>
> On my computer, i currently review 2 big patches :
>
> https://bugs.kde.org/show_bug.cgi?id=155374
>
> .. which will be complex to adapt because they touch a lots of parts
> in digiKam...
>
> Gilles
>
> 2011/8/28 Marcel Wiesweg <[hidden email]>:
>>
>>
>>> Maybe we should consider changing QList to QVector in digiKam's code? With
>>> the patch in the above link Qt will throw a warning when an inefficient
>>> type is used in the QList container.
>>
>> QList is much more convenient IMO. Most importantly, Qt API usually takes
>> QLists and not QVectors, and a conversion may render any won time to a loss.
>>
>> I suggest therefore only to think of conversion if profiling proofs that QList
>> usage is a problem (*)
>>
>> There are places in digikam code where this has already been done: Most
>> importantly, in DigikamKCategorizedView, and in ImageFilterModel
>>
>> (*) For our needs, QList will get problematic if the stored object is larger
>> than a pointer, and or not movable. In profiling, the construction and
>> destruction of the object will then become noticeable. Unfortunately, two
>> important and extensively used classes are problematic in this regard:
>> QModelIndex and QVariant. But Qt API uses QList everywhere for those, so
>> QVector is often not an option.
>>
>> Marcel
>> _______________________________________________
>> Digikam-devel mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-devel
>>
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Francesco Riosa]

I don't promise anything but I want to have my split database work for
the earliest times after 2.1.0 release, hopefully for sunday. It does
touch mostly database code tough.


On 08/28/11 18:05, Gilles Caulier wrote:

> Forget to said that i will apply patches just after 2.1.0 release.
>
> Gilles
>
> 2011/8/28 Gilles Caulier<[hidden email]>:
>> Andi,
>>
>> Before to patch in this way, i sugest to way 2.1.0 release planed next sunday.
>>
>> On my computer, i currently review 2 big patches :
>>
>> https://bugs.kde.org/show_bug.cgi?id=155374
>>
>> .. which will be complex to adapt because they touch a lots of parts
>> in digiKam...
>>
>> Gilles
>>
>> 2011/8/28 Marcel Wiesweg<[hidden email]>:
>>>
>>>
>>>> Maybe we should consider changing QList to QVector in digiKam's code? With
>>>> the patch in the above link Qt will throw a warning when an inefficient
>>>> type is used in the QList container.
>>>
>>> QList is much more convenient IMO. Most importantly, Qt API usually takes
>>> QLists and not QVectors, and a conversion may render any won time to a loss.
>>>
>>> I suggest therefore only to think of conversion if profiling proofs that QList
>>> usage is a problem (*)
>>>
>>> There are places in digikam code where this has already been done: Most
>>> importantly, in DigikamKCategorizedView, and in ImageFilterModel
>>>
>>> (*) For our needs, QList will get problematic if the stored object is larger
>>> than a pointer, and or not movable. In profiling, the construction and
>>> destruction of the object will then become noticeable. Unfortunately, two
>>> important and extensively used classes are problematic in this regard:
>>> QModelIndex and QVariant. But Qt API uses QList everywhere for those, so
>>> QVector is often not an option.
>>>
>>> Marcel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel