Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: KMail: Sluggish almost beyond belief



 Nicholas Bodley wrote: 
> I'm guessing one of two things: A configuration problem that slows normal 
> functions to a crawl, or the KDE developers' use of a bloatware high-level 
> language that in practice produces dismally inefficient executables (or 
> misuse of X Window functions, by any chance?). 

I doubt it's the latter.  I haven't used KMail in a few years, but here's 
some things to look at: 
 - if your home dir is on NFS, and you don't have the NFS locking daemon 
working, things that need to lock usually fall back to a very inefficient 
locking method. 
 - change the format of the mailbox.  If it's currently mbox, try it as 
maildir (or visa-versa).  See this for some fun discussion: 
http://www.courier-mta.org/mbox-vs-maildir/#theend


> As to unresponsive UIs, I came across an interesting interview* with a 
> developer (CK, just about sure; very distinctive name) who did Many Good 
> Things for the kernel, but said farewell to helping with kernel 
> development, iirc because he felt that senior Linux developers apparently 
> didn't care much about UI response times and such. 
> *in an online Australian (iirc!) journal (apc? I know APC makes UPses...) 

I wonder what the issue was specifically, since the kernel has been 
incorporating a lot of the low-latency/real-time patches lately, mostly in 
the name of audio support.  To me, that seems like probably the same type of 
stuff the kernel would need to manage UI response times... 

Matt 

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss
 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org