Re: [Pan-users] Slowness with long discussion threads...

[i443chu8]

-------- Message initial --------
De: Dave <address@hidden>
Reply-to: address@hidden
À: address@hidden
Objet: Re: [Pan-users] Slowness with long discussion threads...
Date: Tue, 4 Oct 2016 09:55:21 +0000 (UTC)

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.

Thank you for your answer.
Pan is not the only application involved, but it is the more affected.
As it appeared to be a local display problem, I tried to access pan from another
workstation over ssh: no delay. I then tried to access pan on the same machine
over ssh again (ssh -X localhost pan): no delay.
Pan is not at the origin of the problem.

Many thanks for your replies again.

PA