[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] kabc question
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-05-28 20:33:34
[Download RAW message or body]

On Monday 27 May 2002 21:06, Reinhold Kainhofer wrote:
>
> Whenever one sets any of the attributes of an addresse (e.g. given
> name, family name, title, note, email, address etc.), the
> KSharedPtr<AddresseeData> gets cloned and the copy is assigned to
> mData again (ensuring that only the data of that very Adressee is
> changed). The old data gets deleted (if (!count--) delete this; in
> ksharedptr.h) and an exact copy is created instead...
> While this is fine for small changes in an addressee, when syncing a
> complete addressbook (with >200 addresses) where each entry syncs
> about 10-20 fields, this means 2000-4000 such cloning and reassigning
> operations in vain (of the whole data structure: a.mData = new
> AddresseeData; *(a.mData) = *mData; this copies all the data in the
> structure, doesn't it?), because just one for each addressee at the
> beginning of the sync would also suffice. And even that could be left
> out.

That's a very interesting observation. I think you are right. Seems like 
you are the first one taking such a deep look into libkabc ;-)

> Can't we introduce a startNoDetach() and an endNoDetach() function to
> prevent this kind of unnecessary copying from taking place? (or
> invent some other way to set multiple data fields at once without
> detach()ing)

What about the attached patch?

> I don't know yet if this hurts performance in any way (just started
> rewriting the abbrowser conduit), but I certainly don't like
> redundant operations being done -- at some point they will sum up,
> and fast processors and memory are no excuse (that's Java's way of
> thinking, and it shouldn't be KDE's).

You are right and it does hurt performance, especially with a fast 
backend like the new binary format.

> Please enlighten me if I misunderstood something about KSharedPtr
> (this is actually my first contact with that kind of idea, and I
> think it is a great idea and has a lot of potential, good as well as
> bad potential if used in the wrong way).

It's a very nice idea, but as you see it's hard to get it right. The 
good thing is that the user of the API doesn't have to care about it at 
all.

-- 
Cornelius Schumacher <schumacher@kde.org>
["detach.patch" (text/x-diff)]

Index: addressee.cpp
===================================================================
RCS file: /home/kde/kdelibs/kabc/addressee.cpp,v
retrieving revision 1.26
diff -u -3 -d -p -r1.26 addressee.cpp
--- addressee.cpp	2002/05/28 10:35:32	1.26
+++ addressee.cpp	2002/05/28 20:16:53
@@ -94,6 +94,7 @@ Addressee Addressee::copy()
 
 void Addressee::detach()
 {
+  if ( mData.count() == 1 ) return;
   *this = copy();
 }
 

_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]