Comparing KFileItems

Frank Reininghaus frank78ac at googlemail.com
Fri Oct 19 08:53:15 BST 2012


Hi,

2012/10/19 Michael Pyne:
> On Thursday, October 18, 2012 13:54:09 Frank Reininghaus wrote:
>> There are ways to fix or work around this problem inside Dolphin, but
>> I'm wondering if it makes sense to change the way KFileItems are
>> compared. If two items do not have the same d pointers, one could
>> check if their URLs are equal and consider them equal in that case.
>> Or, if that is not considered suffient for equality, do what
>> KFileItem::cmp(const KFileItem&) does.
>>
>> I see the following advantages and disadvantages:
>>
>> Pro:
>>
>> a) The implicit sharing is an implementation detail of KFileItem. At
>> least I would not have expected that operator==() depends on this and
>> only compares the d pointers.
>> b) It could possibly prevent other bugs in the future and save debugging
>> time.
>>
>> Con:
>>
>> Changing the way KFileItems are compared could considerably slow down
>> comparisons of items which are not equal.
>>
>> Any opinions about this?
>
> Well, your pros are both correct (and you didn't even list that the current
> behavior is inconsistent between KFileItem::cmp() and KFileItem::operator==()
> ;). But also, you list high CPU usage as a possible con, even though it's what
> got you into troubleshooting this in the first place!

Well, the high CPU usage we get in Dolphin is sort of an accident -
there are ways to work around this even if KFileItem::operator==() is
not changed. On the other hand, changing the behaviour will always
slow down comparisons of KFileItems that are really not equal. I don't
know if this would be a big concern, but I can't see any other good
reason why the current implementation is as it is.

> I would recommend comparing the d-ptrs as done now as an early optimization
> and then falling back to KFileItem::cmp() (or the inlined equivalent) if the
> d-ptrs are different.

That sounds very reasonable to me. Does anyone whith more insight into
common uses of KFileItem (David maybe?) have any objections?

Best regards,
Frank




More information about the kde-core-devel mailing list