On Friday 25 Nov 2011 13:01:33 Will Stephenson wrote:
Secondly, all mail is indexed by default.
I didnt really mean to type such a long email but once I started it just kept going, apologies.... I've noticed the high load that Adrian talks about, but it's only when I *initially* add IMAP accounts with thousands of emails, few 30k folders in there, only one with as much as 80k and none above 100k. But I have a lot of these folders, so some accounts easily have over 200k emails in total. So I assumed it was just indexing as much as it could after adding these accounts and I just let it churn away. I've no idea how long it took to index everything because I left it overnight and went to bed; but it was easily pegging a full core and possibly more while it was doing it's thing. So I can imagine this might be pretty annoying on a netbook or laptop. However there's a bright side! I've honestly not experienced this high load since I let everything get indexed and I'm actually happier with Kmail, Akonadi and Strigi all running and *not* being noticable in any way now. Nepomuk actually being useful and fast to search email contents and find them using krunner makes me happy as a pig in *$#! So I'm convinced after the initial indexing, Kmail and Nepomuk is actually in a pretty good place but this initial load is certainly an annoyance, and since there are no warnings about what is going on to create the load it can look pretty bad to the user. Perhaps there should be a user notification/warning that indexing may take some time? There's one other issue that I see occasionally, I'm trying to find a reproduce case for it, I think I'm almost there; and I think it may exagerate the problems people are seeing when the try to setup kmail2 for the first time. The issue I'm seeing is that if I perform a "batch" operation in kmail, say deletion of 5k emails, then any other action to view emails, mark as read etc are blocked for a while. A brief poke at ~/.xsession-errors shows it filling up with the following type of lines, at about 2 per second. So if this corresponds to each deleted email, and at a rate of approximately 2 per second, then my mail viewing is blocked for some time. 14212 +FLAGS (\Deleted) 14213 +FLAGS (\Deleted) 14214 +FLAGS (\Deleted) 14215 +FLAGS (\Deleted) 14216 +FLAGS (\Deleted) 14217 +FLAGS (\Deleted) [/usr/bin/nepomukservicestub] virtual void Soprano::Server::LocalServer::incomingConnection(quintptr) [/usr/bin/nepomukservicestub] void Soprano::Server::ServerCorePrivate::addConnection(Soprano::Server::ServerConnection*) New connection. New count: 15 [/usr/bin/nepomukservicestub] Soprano::ODBC::Connection::Connection() Soprano::Server::ServerConnection(0x17ba730) void Nepomuk::Query::QueryServiceClient::close() 14218 +FLAGS (\Deleted) 14219 +FLAGS (\Deleted) 14220 +FLAGS (\Deleted) 14221 +FLAGS (\Deleted) 14222 +FLAGS (\Deleted) 14223 +FLAGS (\Deleted) 14224 +FLAGS (\Deleted) 14225 +FLAGS (\Deleted) 14226 +FLAGS (\Deleted) etc etc etc... So it really wouldn't surprise me if nempomuk is also blocking mail viewing while the initial indexing is taking place, which pretty much looks to the user that everything is frozen and broken, which it actually is in a sad way even though things are churning over in the background. So yeah nepomuk feeders for email should be off by default until the initial indexing is less painfull and resource hungry, I'm pretty much convinced peoples kmail issues would almost all dissapear. Personally I'm leaving nepomuk turned *on* because really, truthfully and honestly, it's actually working pretty nice for me with some pretty large IMAP folders. I can't say the same for IMAP in the previous Kmail ;) Cheers the noo, Graham -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org