D pointers

[Lubos Lunak]

On Tuesday 04 of October 2005 13:32, Dirk Mueller wrote:
> On Saturday 01 October 2005 19:58, Lubos Lunak wrote:
> >  To repeat it once more, unless somebody can find a problem with my KURL
> > benchmark then register pressure on our most significant platform seems
> > to cause about 2% performance loss and that's how valid the point is.
>
> Your benchmark is useless because my point about KURL was that inlining the
> accessors gives a speedup, not the flattening of d-pointer.

=====
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.
=====

All inlines are written as following in the test code:

=====
kurl2.h:
#ifdef MOVE_PRIVATE
  bool hasUser() const;
#else
  bool hasUser() const { return !m_strUser.isEmpty(); }
#endif

kurl2.cpp:
#ifdef MOVE_PRIVATE
...
#define m_strUser d->m_strUser
...
#endif
#ifdef MOVE_PRIVATE
...
bool KURL2::hasUser() const { return !m_strUser.isEmpty(); }
...
#endif
=====

 So #defining MOVE_PRIVATE removes performance effects of both flattening and 
inlining, as far as I can say, so those 2% account for no inlining and 
something more. Or am I missing something?

 KURLTest doesn't seem to use loops over KURL or similar code that'd probably 
get higher benefit from inlining, but then I doubt most real code would do 
that either.

-- 
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/