[haiku-development] Re: Working on Haiku's Mail app
- From: Alexandre Deckner <alex@xxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 03 Dec 2009 23:29:02 +0100
Axel Dörfler wrote:
"Jorge G. Mare" <koki@xxxxxxxxxxxxx> wrote:
Back in the day, when I used to demo ZETA at various events and
conferences (remember the good old days BGA?! :) ), that's exactly
what
I used to do: I had 30 - 40K emails, I would run queries with
multiple
criteria that would give me anything between a few dozen to several
hundred hits, and it worked reasonably well to support the claim of
live
queries. You make it sound like only a miracle would make this
possible
in Haiku, but I think it's more a matter of giving the devs time to
resolve the existing issues; hopefully I am not being naively
optimistic
here... :)
There is currently obviously a snooze() in Tracker that makes it so
slow (IIRC). Queries from the Terminal are magnitudes faster.
The speed problem Joachim mentioned stems from 1000s of results, not
10000s of mails total. And that will continue to be a problem.
I've been doing some experiments and benchmarks recently that
follows previous work on this (yes the performance was exponentially
worse before, but that work had to be put on low priority considering
the more important crashing bugs to fix).
After working and being really pleased with queries in a console
experiment, i was motivated again and added some in-code benchmarking
to try new things and obtained those theoretic terminal-like response times.
(for those who want an idea, jam live_query and admire your favorite OS).
So it's definitely doable, but needs some reimplementations in some places.
One of the remaining culprits for example is the insertion sort that
seems to
be terribly inefficient either graphically or in the data structure.
I will resume that work soon although (for those who don't know)
even after months of bug fixing, cleaning, and light restructuring,
it's a real nightmare to do anything in the fragile Tracker code,
so wish me luck :)
Now talking about snooze, actually there is a half millisecond snooze
each 50 pose, that i was forced to introduce as a workaround,
like a year ago, that was needed to prevent some serious (and mysterious)
lockups after fixing another bug in the threaded pose loading.
After the recent fixes (code sprint) to the ports system which might
be unrelated btw, i decided to reconsider this and after testing
for a few days, it seems we can do without now. However this only
accounts for a very small (and linear) fraction of the slowdown,
the real problems are in the paragraph before :)
Regards,
Alex
Other related posts:
