D pointers

[Lubos Lunak]

On Thursday 29 of September 2005 13:49, Lars Knoll wrote:
...
> The main issue is usually that inlining looks like it makes things fast,
> but without measuring you do not know where your bottlenecks are. In most
> cases they are not the accessors for simple properties. But inlining might
> prevent future optimisations of your class. So in general I think one
> should not inline unless there is a _very_ good reason to do so.
>
> Having method inline makes sense in one case: When you have a lowlevel
> class that you need to use in tight inner loops where you process lots of
> data. Basically container classes as QString, QList etc. But then you have
> to invest lots of resources to make sure you can live with the
> implementation for the lifetime of KDE4. But even then you usually put the
> data into a d-pointer to be able to use implicit sharing.
>
> The good old rule that you shouldn't optimise without having measured also
> applies here. The gained flexibility by having the data structures hidden
> usually more than outweighs a loss of speed that is in most cases not even
> measurable.

 Some of those numbers. Short version: Changing KURL to use d-pointer for 
everything costs less than 5% performance in kurltest. I think 5% in this 
case is something we should not be really concerned about.

 Longer version: Attached is a slightly modified KURL + kurltest. Without any 
d-pointer this test takes 6,71s. In kurl2.h there are three #defines, 
PRIVATE_SIZE just causing allocation and deallocation of KURL2Private of the 
given size. After setting it to 4 time goes up to 6,73s, the only difference 
is one allocation in ctor and one deallocation in dtor. Note however that the 
malloc implementation is optimized for very small sizes, changing 
PRIVATE_SIZE to 70 changes the time to 6,81s. #defining also MOVE_PRIVATE 
makes all the data members to be moved to the d-pointer, which also means one 
more indirection and no inlining. That changes time to 6,84s. Additionally, 
because the KURL2Private this way is only 32bytes here, i.e. small, setting 
EXTRA_SIZE to 70 makes it exceed the size for the fastest allocation 
mechanism, then the time is 6,87s.

 Summary: The worst case takes 102,5% of the best case. And there are 360000 
allocations of KURL2Private in the whole test BTW. Unless I got something 
wrong with this, the performance impact is negligible. Conclusion is left as 
an exercise to the reader.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ku.tar.gz
Type: application/x-tgz
Size: 38468 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050930/b125e27e/attachment.bin>