On Mon, 2003-12-01 at 12:10, Meilof wrote: > Hello, > > I'm working on NNTP support in Evolution, particularly the subscription > interface currently, but I've encountered some problems. > > First, I've written the code that contact the news server for a list of > newsgroups by implementing nntp_store_get_folder_info using the code > from camel-nntp-grouplist.c. For my test news server, which has > something like 5 newsgroups, this works pretty well, and the groups show > up nicely in the subscription dialog, but for the news server of my ISP, > which has _much_ more groups, I find the subscription dialog to be way > too slow. After the nntp_store_get_folder_info code has returned, and > the complete newsgroup list is in, on my PC, a 2GHZ box, it still takes > the dialog about five *minutes* to finally display the information, time > during which Evolution totally locks up (apart from also consuming a > huge amount of memory).
if the subscribe dialog already freeze()'s and thaw()'s the gtktreeview when adding nodes to the tree, then this performance problem sounds like a GtkTreeView bug. Otherwise we need to add freeze/thaw. I'll check up on this in a few minutes. > > Maybe the best approach would be not to show all groups at once, but to > have a search dialog box or a tree structure or something, or the > subscription dialog should be optimized to be able to handle large > amounts of folders. Are there any easy solutions for this? I'd rather not have to resort to this. perhaps (assuming freeze/thaw doesn't help) we can do some sort of chunking - adding a handful of nodes and then giving gtk time to breathe and then adding a few more. > > Another thing: quickly looking at em-subscribe-editor.c, I found there > is no difference between the initial loading of the folder list and > subsequent loadings with the "Reload" button from the subscription > dialog. For news servers that don't support the NEWGROUPS and DATE > command, this would mean every time the dialog pops up, the complete > newsgroup list needs to be loaded, which might get a little irritating > after a while, especially if it remains this slow. Do you think this is > acceptable, or should I look whether I can do anything about it? you might look into caching the result of the folder list query. Jeff > > > Meilof > -- [EMAIL PROTECTED] > > _______________________________________________ > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers > _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
