> Hi, > thanks, the backtrace looks fine. One thread is synchronizing all your > Search Folders, while another thread is storing summary information for > one of those search folders. I guess the CPU usage is high during this > time, maybe for whole 20 minutes. This all depends on the number of > search folders you've defined. The other threads are basically idle, > thus the long time is only about search folders and their > synchronization (the current "camel_folder_refresh_info_sync" > implementation in search folders seems to rebuild itself, which means to > clear itself and refill from scratch - it seems to me that this refresh > call is not needed on search folders when going to quit, on the first > look). > > I'm not aware of any workaround for this. It would be good if you could > file this in bugzilla [1], thus it'll not be forgotten. If you could > attach there two backtraces, one after those 30 seconds, another say > after 5 minutes of "inactivity", and confirm or falsify the high CPU > usage, with a note of how many search folders with approximately how > many folders in them you have, and what those real folders are from (On > This Computer, IMAP, ...) and an approximate message count in folders. > (The backtrace also shows that it's trying to update Unmatched search > folder). > > Please do not forget to post here the bug link, for a reference. > Thanks and bye, > Milan Milan, Reported on Bugzilla - bug 676072
_______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-list
