[Kde-pim] Excessive amount of queries

[Martin Steigerwald]

Am Sonntag, 7. Dezember 2014, 22:21:58 schrieb Aaron J. Seigo:
> On Sunday, December 7, 2014 21.49:02 Martin Steigerwald wrote:
> > Am Sonntag, 7. Dezember 2014, 19:28:56 schrieb Aaron J. Seigo:
> > > On Sunday, December 7, 2014 16.42:08 Martin Steigerwald wrote:
> > > > > I think you are missing the point, Aaron. The question should be:
> > > > > Why
> > > > > do
> > > > > we
> > > > > even need 500k query round trips per second for a mail application?
> > > > 
> > > > I think that is a very good question.
> > > 
> > > The answer is in the math.
> > > 
> > > (1 / 500000)second/query == queries cheap enough to not worry if you are
> > > firing 1000 queries a second. 1000 queries becomes 1/500th of a second
> > > (there  is sloppiness in that math; it will almost certainly be more
> > > than
> > > that, but not by an order of magnitude).
> > 
> > I think… it still matters. Cause its the attitude in my eyes that makes
> > all
> > the difference.
> 
> I'm suggesting we put that attitude in the frameworks underneath the
> application code.
> 
> then application code matters a lot less.

Well, I am fine with that as long as it gives the desired result.

> > When I look at this ThinkPad T520 with dual SSD BTRFS RAID 1 and dual core
> > Intel Sandybridge i5 with 2,5 GHz, which can overclock itself to upto 3,2
> > GHz and compare it with that Sam440ep 667 MHz PowerPC system running
> > AmigaOS 4.1 from a plain 500 GB SATA harddisk, I easily get the lession
> > about what efficiency truly means
> 
> i <3 amiga :)
> 
> my focus is very very much on efficiency and performance. the current
> akonadi is amazingly inefficient and, just as bad, pushes complexity
> outwards (a symptom is having to add caches to what is really a caching
> system). the developers worked with what they had at the time, and i do not
> fault them for that one bit, but what they had wasn't efficient.

Hmmm, I concur with that. I have seen it with my, admittedly huge mail setups.

> we can make akonadi efficient enough with today's concepts and tehcnology
> that our current "inefficient" application code just wont matter much
> anymore. tweaking things like "we ask for the number of messages in a
> folder 100 times" simply will not matter because it will not show up
> anywhere near the top of a profiling run.
> 
> this, btw, is really how those old platforms achieved most of their
> efficiency: they took all sorts of shortcuts and did amazing / ridiculous
> optimizations below the applications. toolkits in ROM, crazy assembler
> tricks ... yes, the apps were also written by people who cared ... but when
> the OS below you is insanely optimized it doesn't matter quite as much.

Well, I concur that fixing things at the lower level benefits all the 
applications while trying to optimize the application may only fix that one 
application to the extent the lower level toolkit or framework permits.

Still if an applications does something a hundred times or a thousand times 
that it can do 5 or 10 times, its still something to consider IMHO. Like the 
KDE clock updading only each minute if time precision is set to minute, and 
not every second. Sure, it may not matter very much, but its still nice this 
way.

> (i was there :)

Nice.

> > And it matter related to power consumption anyway… everytime things can go
> > in sleep states as they do not have to do anything, you save power. Thats
> > important for any kind of portable devices. And it is also important in
> > general.
> 
> time to completion is (almost) all that matters for that.

Yeah sure. The quicker its done, the longer it can sleep. Thats why the 
frequency scaling even uses turbo mode of Intel Sandybridge processor to get 
things done faster.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/