Re: Goodbye for now, kmail
Gianluca <[email protected]>
| Newsgroups | gmane.comp.kde.users.pim |
|---|---|
| Message-ID | <20170506110716.1814e72e@galactica> |
On Sat, 06 May 2017 01:09:26 +0200 Daniel Vrátil <[email protected]> wrote: > > Pablo Sanchez - 05.05.17, 09:06: > > - Akonadi does more needless work: I reported several other bug > > reports. > > Akonadi does a lot of work. When you implement a very generic service > like Akonadi, it's going to perform better in some cases and worse in > other ones. You can't implement a generic service that performs 100% > in all cases. You are right, a generic service like akonadi has to do a lot of work, but it seems to have some fundamental design flaws, since it is 5 years old and, in my opinion, still far away to be called "production ready" > > - Akonadi does not auto-tune MySQL performance settings like InnoDB > > buffer pool size with is ridiculously low after anything than a few > > mails. A too low InnoDB buffer pool size leads to additional file > > I/O accesses. > > innodb_buffer_pool_size has been doubled in 17.04 release (to 128MB). Right, but it seems still to be way too lower. Moreover, with todays systems, this seems to be very low anyway, also given how akonadi depend on the custom copy of mysql. > Sink has some very good concepts that I like and we will be gradually > evolving Akonadi towards those concepts. But I don't want to walk > down the route of "let's throw everything away and start from > scratch" though. Sometime the route "let's throw everything away and start from scratch" is a better solution than "let's try fix all the probems" simply becacuse you already know all the problems you will have and can design the system with them in mind, instead of trying to find a workaround in a flawed design. bye Gianluca