Dave posted on Sun, 02 Oct 2016 11:04:05 +0000 as excerpted: >> I use Pan 0.139 on Ubuntu 16.04 LTE. >> Since I upgraded to version 0.139, I observed very long response times >> when a thread contains many posts. Pan uses 100% cpu for tens of >> seconds before the selected posts appears. In previous versions, there >> was almost no delay. >> >> I trimmed my Score file, with no result. >> Am I the only one with this problem? >> >> > No issues here with Pan 0.140
Also no issues here -- live-git pan (will be 0.141, git commit is in the headers as I'm posting with pan, I've not updated in ~1 month, tho). As the others have suggested: * How many posts is many posts? * 0.139 is indeed old, and may be bugging out if built with a newer gcc or against newer libs. Further comments of my own: * Pan builds a threading tree at startup. The larger your message cache and/or the longer you keep overviews/headers b4 expiring (I'm actually not sure which), the longer startup will take, especially on spinning rust (not ssd). However, as a result of that it shouldn't take long to switch groups or for new messages to load, even in long threads, because it's all in memory already. (FWIW this is also one reason pan uses so much memory if you're loading very active binary groups.) So something else is happening if it's taking tens of seconds for a post to appear. * You might try setting the expand all threads when entering group option if it's not set (preferences, behavior tab, under groups), then select a bunch of messages and hit the cache article function (articles menu). That will download them to cache all at once. (In binary groups you won't be able to do too many unless you've increased your article cache size beyond the default 10 MB, or it'll start deleting them again when it reaches that. Cache size is set in prefs, behavior tab, under article cache.) Then try clicking on the already downloaded to local cache messages. Does it still take a long time to display the message when it's already cached? * If the messages display right away when they're already cached, it's probably a network or server problem as they're displaying fine when they're local. * If the messages still take a long time to display when they're already cached locally, it's a pan display problem, possibly a bug in pan, or possibly a problem due to building it with a newer gcc or against newer libs. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
