D9236: Fill lists of default-constructed types directly, not append any by value

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In https://phabricator.kde.org/D9236#177743, @aaronpuchert wrote:
  
  > It might not actually be faster though, because you go through the memory twice. If the vector doesn't fit into the cache, that could introduce quite some slowdown.
  
  
  I see. (Thanks for reply, really interested in this but never looked at details in the last years, so happy about input and discussion. Please bear with me being naive and uninformed for now)
  
  > On the other hand, copying deep objects can obviously be costly. Some of the vector element types seem to carry around some baggage.
  > 
  > The C++11 way would be to move such objects, can we do that? It seems to be supported via `QVector<T>::push_back(T&& t)`.
  
  I still have to complete my C++11 classes sadly. In my naive mind I would have hoped something like this would be possible, in general:
  
    alloc heap memory for list items
    for each item
        default constructor item on heap
        setup item on heap
  
  I would not see any principal need to prepare the item on the stack. Is there? Why would C++11 still prefer a move operator, instead of going directly for the final memory destination?
  
  With QVector it seems there is some practical need for a separate item instance only because the API does not have any hooks for some iterator-based filling, any item construction is hardcoded to the default constructor. One could image some `fill(int count, functor constructor)` or some `T& appendNew()`. But it isn't there after all the years, despite list filling from a loop surely being a common need. Would that be an anti-pattern for some reason?
  
  No real clue yet about move operators, but how does it spare us here any constructor and deconstructor calls? And with the QType-sub-datastructures being implicitly-shared usually, does the move operator make a difference when it comes to unneeded temporary allocations?

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D9236

To: kossebau, #kdevelop
Cc: aaronpuchert, brauch, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20171209/41e1a179/attachment.html>