KWalletD syncing

David Faure faure at kde.org
Fri Jun 13 13:28:59 BST 2008


On Friday 13 June 2008, Michael Leupold wrote:
> Am Freitag, 13. Juni 2008 schrieben Sie:
> > > usually what i do in such situations is move the syncing to a slot and
> > > then call that slot with either a zero timer (so as soon as the event
> > > loop gets hit again) or a reasonably short timeout[1] from the places
> > > that a sync should be triggered.
> > Yeah, you're absolutely right. Coincidentally this is exactly what came to
> > my mind when I started sipping my first coffee this morning 10 minutes ago
> > :-)
> 
> Okay, I reworked the whole patch to behave like this:
> - On changing the wallet's contents, start a 5 second timer
> - sync the wallet when this timer times out
> - restart the timer if another change occurs while it's running (to prevent 
> multiple syncs on importing/merging)

I'm very happy about this fix, this problem bothered me for a long time :)
I agree with the timer-based approach.
Implementation-wise, I'm surprised there is no "wallet" object backend in the
backend, it would have been the obvious place for this timer; but if there isn't
one then indeed an out-of-band timer object associated with a wallet name is
the only solution.

> > > that way if multiple syncs get called in a row (or, at least, within the
> > > timeout period) you get just one sync instead of repeated syncs.
> > > btw, have you tested the performance impact of this with large wallets?
> > > [1] what "reasonably short" means is very much up to the exact
> > > application being considered.
> > I've benchmarked up to 10000 entries in the wallet (20 byte key, 50 byte
> > value). Syncing it took about 56ms on my Q6600 in release mode.
> 
> I benchmarked the whole procedure inside kwalletd now. I chose 100 byte keys 
> and 20 byte passwords which I assume is more than average. Please note that 
> the benchmarking is done in a debugfull build. Prior benchmarking 
> (http://techbase.kde.org/Projects/Utils/kwallet/Benchmark) indicates times in 
> a release build will typically be less than 1/3:
> - 1000 passwords: 49ms
> - 5000 passwords: 222ms
> - 10000 passwords: 445ms

Seems OK to me. Especially compared to kwallet losing my newly entered passwords
all the time :)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




More information about the kde-core-devel mailing list