Pan 0.139 very slow with long threads... appeared with the new version

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Pan 0.139 very slow with long threads... appeared with the new version

i443chu8


Hello,

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?


PA

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pan 0.139 very slow with long threads... appeared with the new version

Dave-58
On Sun, 02 Oct 2016 10:12:27 +0200, i443chu8-GANU6spQydw wrote:

> Hello,
>
> 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

0.139 has been superseded for quite some time by 0.140 so it's entirely
possible that that some interaction between Pan and one or other support
library or programme which has since been updated is causing some issue
such as a race condition or just not sending back data in the way Pan
expects it.  Have you updated everything else installed too?

I've not used Ubuntu for a few years now, but isn't there a contact email
address for the person maintaining the Ubuntu build of pan for the
repositories?  Go through the package manager as if to install pan and
check the info/tabs since that person is most likely to be able to help
in this case.

In the mean time, are you certain it's the Pan task taking 100% of CPU
time?  You could try htop in treeview mode or pstree to see if Pan is
calling other tasks

Other dependencies to check on are (list from my FreeBSD install):

   /usr/ports/accessibility/atk
   /usr/ports/converters/libiconv
   /usr/ports/devel/gettext-runtime
   /usr/ports/devel/glib20
   /usr/ports/devel/pcre
   /usr/ports/mail/gmime26
   /usr/ports/security/gnutls
   /usr/ports/textproc/gtkspell
   /usr/ports/x11-toolkits/gtk20
   /usr/ports/x11-toolkits/pango

A few of those are text/language/locale related and will be called when
displaying subject lines in the headers pane or messages in the body pane.
Note that gnutls has been patched a few times in recent months and your
build may have slightly different dependancies depending in what make
options the builder chose.

--
Climate Change may be raising the sea levels, but the gene pool
seems to be drying up.


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pan 0.139 very slow with long threads... appeared with the new version

Jim Henderson-4
On Sun, 02 Oct 2016 11:04:05 +0000, Dave wrote:

> No issues here with Pan 0.140

Nor here, running 0.141 (which actually surprised me).  In fact, I was a
participant in a thread that has about 700 messages, and saw no problems
at all with performance.

I guess one question for the OP would be "what constitutes a long
thread?".

Jim

--
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pan 0.139 very slow with long threads... appeared with the new version

Duncan-42
In reply to this post by Dave-58
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pan 0.139 very slow with long threads... appeared with the new version

Jean-Pierre MORLET
In reply to this post by Jim Henderson-4
-------- Message initial --------
De: Jim Henderson <[hidden email]>
Reply-to: [hidden email]
À: [hidden email]
Objet: Re: [Pan-users] Pan 0.139 very slow with long threads...
appeared with the new version
Date: Sun, 2 Oct 2016 21:14:46 +0000 (UTC)

On Sun, 02 Oct 2016 11:04:05 +0000, Dave wrote:

>
> No issues here with Pan 0.140
Nor here, running 0.141 (which actually surprised me).  In fact, I was

participant in a thread that has about 700 messages, and saw no
problems 
at all with performance.

I guess one question for the OP would be "what constitutes a long 
thread?".

Jim

Many thanks for your informative answers. 
They lean to indicate some local problem.
The slowness becomes noticeable with threads around 100 messages,  
Pan 0.139 is the version currently available from Ubuntu standard
repositories. 

PA

_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pan 0.139 very slow with long threads... appeared with the new version

Jim Henderson-4
In reply to this post by Jim Henderson-4
On Mon, 03 Oct 2016 17:38:21 +0000, hiker wrote:

> On Sun, 02 Oct 2016 21:14:46 +0000 Jim Henderson wrote:
>
>> Nor here, running 0.141 (which actually surprised me).  In fact, I was
>> a participant in a thread that has about 700 messages, and saw no
>> problems at all with performance.
>
> What is version 0.141? On git I only see version 0.140?

It's what I pulled and built myself - I've got commit 46c521 checked out
at the moment.

Jim

--
 Jim Henderson
 Please keep on-topic replies on the list so everyone benefits


_______________________________________________
Pan-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Pan 0.139 very slow with long threads... appeared with the new version

Duncan-42
Jim Henderson posted on Mon, 03 Oct 2016 20:21:09 +0000 as excerpted:

> On Mon, 03 Oct 2016 17:38:21 +0000, hiker wrote:
>
>> On Sun, 02 Oct 2016 21:14:46 +0000 Jim Henderson wrote:
>>
>>> Nor here, running 0.141 (which actually surprised me).  In fact, I was
>>> a participant in a thread that has about 700 messages, and saw no
>>> problems at all with performance.
>>
>> What is version 0.141? On git I only see version 0.140?
>
> It's what I pulled and built myself - I've got commit 46c521 checked out
> at the moment.

I'm about a month outdated ATM (see the moving... thread), but I can
confirm, 0.141 is pan git.  The policy appears to be bump the version
number in git right after a release and include git commit hash as well.  
That way the version number shows the relative age, including unreleased
head if applicable, and the commit hash can be used to narrow down even
further if there's a recent regression or fix to be traced.

I think a useful addition to that would be version bump both for a
release and immediately after, which if started now, with a bump
immediately before the next release and another immediately after, would
mean odd version numbers are git builds and evens are release builds,
much like the old Linux kernel versioning policy, but that hasn't been
the way it has been done to date, just the post-release bump in git (and
before that svn, and before that...).

--
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/pan-users
Loading...