On Tue, 05 Aug 2008 05:46:32 +0000, Duncan wrote: > ... > GL's suggestion, I think, was that it was just taking the time to sort > all those headers, and there wasn't a lot that could be done about it. > I don't believe that's the case, because it's not behaving that way for > everyone, and where it is, it's fairly recent -- it was working fine > some months ago.
And the 32-bit version works as expected, per David. (I think he meant on the same hardware, but I'm not sure.) If you open the event log while fetching headers you will see that pan stops every 10 seconds to rethread. On my machine, with my DSL connection, pan has to readthread about 50-80 articles every 10 seconds, which is trivial and instantaneous. Now if I had a cable connection, which is allegedly 5-10x faster, pan would need to stop and rethread several hundred articles instead of 80. That may not scale very well, but I can't imagine that it would take very long. > ... > Of course, the above assumes you know how to have gdb suspend the run > (the interrupt does that) to do the bt, then resume it, then suspend it > again 30 seconds later, keeping both backtraces (plus a few more in the > suspend/bt/resume/wait30 cycle) to compare them later. I'm not a gdb > guru, so I'd be feeling my way on that too... gdb has a pretty good help facility built in. From it's command prompt type 'help' to see the top-level menu, and then 'help running', for example, to find the 'run' and 'continue' commands, which do exactly what you suggested above. These can be shortened to 'r' and 'c' to save keystrokes. I got a lot of practice when I was working on the incorrect display of multi-part jpegs a few months ago. One nice thing about running gentoo is that you can trivially build debugging symbols into libraries like gtk and glib, which is important for bug hunting in a gtk program like pan. _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
