On Mon, 03 Oct 2016 14:01:32 +0200, i443chu8-GANU6spQydw wrote: > Hi, > > On Ubuntu 16.04, I upgraded to version 0.140 using Klaus Worweg's > binary. http://ppa.launchpad.net/klaus-vormweg/pan/ubuntu/dists/ > > I marked a thread containing 328 posts as not read. > The first post of the thread is accessed almost instantly. > But to reach a post in the middle of the thread, with a large answer > depth, pan used 48 second of intel i3 1.3Ghz processor time. > > PID UTIL. PR NI VIRT RES SHR S %CPU %MEM TEMPS+ COM. > 3980 pa 20 0 270716 149884 29644 S 0,3 8,4 6:10.81 pan > 3985 pa 20 0 270716 149884 29644 S 0,0 8,4 0:00.00 dconf > worker 3986 pa 20 0 270716 149884 29644 S 0,0 8,4 > 0:00.00 gmain 3987 pa 20 0 270716 149884 29644 S 0,0 8,4 > 0:04.47 gdbus 3990 pa 20 0 270716 149884 29644 S 0,0 8,4 > 0:00.00 pool 3991 pa 20 0 270716 149884 29644 S 0,0 8,4 > 0:00.00 pool 3992 pa 20 0 270716 149884 29644 S 0,0 8,4 > 0:00.00 pool > > The more a post is indented, the longer it takes to display it. > > Any idea? > The fact it's doing the same as with 0.139 for you and not for a range of other people does seem to indicate that it's not Pan but some other library on your system which Pan depends upon.
It could also be a hardware problem, an iffy sector on the hard disk where Pan is maintaining its database or a file system error. I have, on occasion, had odd errors where fsck didn't find anything, but running a full fsck without -y (yes to fix automatically, yes to use journal to fix) did then find errors which it then fixed. Likewise, try smartctl to check the SMART status of the HDD, and maybe run the full surface test to make sure there are no bad sectors or other errors, Wikepedia has a good description of the SMART data points and what they mean. This can take well over an hour for the full scan. If you've never done either of the above, it's probably a good idea to do those tests anyway. Also, a couple of years ago I had issues with Pan threading, ie not threading properly or at all if the thread depth was more than 2 or 3. We eventually narrowed it down to FreeBSD still using an older version of gmime. This may be a complete red herring, my problem was quite different but it was a threading issue caused by gmime and using an older version fixed it until the latest version was made available in the FreeBSD ports system. -- Climate Change may be raising the sea levels, but the gene pool seems to be drying up. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
