From kde-pim  Thu Dec 18 16:24:04 2014
From: "Aaron J. Seigo" <aseigo () kde ! org>
Date: Thu, 18 Dec 2014 16:24:04 +0000
To: kde-pim
Subject: Re: [Kde-pim] Experiences with current Akonadi perf improvements
Message-Id: <3263631.eLQRuL5pjt () serenity>
X-MARC-Message: https://marc.info/?l=kde-pim&m=141891995630615
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--===============0072903417759030877=="


--===============0072903417759030877==
Content-Type: multipart/signed; boundary="nextPart3612230.CbKKcTAnIM"; micalg="pgp-sha1"; protocol="application/pgp-signature"


--nextPart3612230.CbKKcTAnIM
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"

On Thursday, December 18, 2014 13.03:42 Martin Steigerwald wrote:
> 1) Provide good progress report on what each resource is doing. A use=
r who
> sees a process hogging a CPU core without *any* feedback as to *why* =
will
> likely get dissatisfied with it. Of course, if that kind of thing doe=
sn=B4t
> happen with Akonadi Next anymore, this point could be skipped. Or pro=
gress
> report made less often in order to not harm the performance by progre=
ss
> reporting.

Progress reporting isn't yet covered in akonadinext, though it is easy =
to add=20
once we are ready to do so with messages from the resource to the clien=
t.

That said, only *write* operations happen in the synchronizer process i=
n=20
akonadinext. Anything not-a-write operation happens in process. Progres=
s is a=20
lot easier to show in that case, and it is a lot harder to lose connect=
ions,=20
etc ;) This alone will remove a large number of issues currently faced =
in=20
akonadi clients.

In fact, I suspect that the only time we'll end up actually needing pro=
gress=20
is when:

* synchronizing with the source (network traffic and all that)
* manually triggering processes such as "apply all filters to these mai=
ls"

Nothing else will require sending progress between processes.

> 2) Do only work that is *necessary*. Be as lazy as you can get. As I
> suspected for a long time and as recent optimization work has shown:
> Current Akonadi did a lot of work that wasn=B4t necessary. And I thin=
k in
> case of folder synchronization it still does useless work.

Yep :)

=2D-=20
Aaron J. Seigo
--nextPart3612230.CbKKcTAnIM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEABECAAYFAlSS/6QACgkQ1rcusafx20O5SwCfYP80X3zxBHdpoxujBBmpsGlR
4xIAn3zmMWZyrg07fjsCvt4X+OjPKXLQ
=+Pfq
-----END PGP SIGNATURE-----

--nextPart3612230.CbKKcTAnIM--


--===============0072903417759030877==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
--===============0072903417759030877==--