KWalletD syncing

[Michael Leupold]

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)

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

Regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-kwallet-synconchange.diff
Type: text/x-diff
Size: 8699 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080613/f450de75/attachment.diff>