Review Request 111399: Keep the "item size hints" of moved items

[Mark Gaiser]

> On July 5, 2013, 6:56 a.m., Mark Gaiser wrote:
> > Hi Frank,
> > 
> > This is awesome, but i'm a bit concerned about the "m_sizeHintCache". That value is a member of KItemListSizeHintResolver which is kept for the life of KItemListView. Which, if i'm correct, is as long as dolphin is running. So m_sizeHintCache can get quite large if you open massively sized folders, right? So perhaps it's an idea to to apply an LRU algorithm here to keep the cache size down to a certain defined maximum. Perhaps QQcache can do this for you?
> > 
> > For all of this, it's just an assumption and something i noticed. I don't know if it's actually the case. Please do correct me if i'm wrong :)
> 
> Frank Reininghaus wrote:
>     Thanks for your comments, Emmanuel and Mark.
>     
>     The size of m_sizeHintCache is always equal to the number of items in the view. This means that we have a QSizeF (which contains two qreals, i.e., two doubles = 16 bytes) for every item. In other places, we store far more bytes per item (just think of name, size, date, icon name, pointers that are required for the internal bookkeeping of hashes, etc.). Therefore, I don't think that wasting too much memory is an issue in this class.
>     
>     Moreover, you don't get a QCache for free. It does have a certain overhead memory and performance-wise. Internally, it keeps a linked list (i.e., two pointers per item) and a hash that maps the keys to pointers to the list nodes (i.e., about 3 pointers per item if you account for QHash's internal bookkeeping and 1 int for the key). All in all, this rough estimate yields about 44 bytes per item on a 64 bit platform. That's only worth it if either the size of the cached items is much larger than that, or you really limit the size of the cache to a very small number of items. But then we would have to re-calculate the item size very often when a single item is inserted, removed, or its name is changed.

Thank you for the well explained details! :)


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/111399/#review35612
-----------------------------------------------------------


On July 4, 2013, 10:20 p.m., Frank Reininghaus wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111399/
> -----------------------------------------------------------
> 
> (Updated July 4, 2013, 10:20 p.m.)
> 
> 
> Review request for Dolphin.
> 
> 
> Description
> -------
> 
> Calculating the "item size hint", i.e., the size that is required to show an item including its full name, is quite expensive in Icons and Compact View. Therefore, it makes sense to keep them even if items are moved (the current code just throws them away and recalculates them the next time KItemListViewLayouter::doLayout() is called).
> 
> 
> Diffs
> -----
> 
>   dolphin/src/kitemviews/kitemlistview.cpp 2ea6657 
>   dolphin/src/kitemviews/private/kitemlistsizehintresolver.h 5ec5f4a 
>   dolphin/src/kitemviews/private/kitemlistsizehintresolver.cpp 5db87f3 
> 
> Diff: http://git.reviewboard.kde.org/r/111399/diff/
> 
> 
> Testing
> -------
> 
> When enabling the timer in KItemListViewLayouter::doLayout(), I see that the time required for a relayouting after changing the sort order or renaming a file is decreased significantly.
> 
> 
> Thanks,
> 
> Frank Reininghaus
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130705/d85912d6/attachment.htm>