Re: [Pan-users] speed of "Get new articles"

[Gert]

Charles Kerr (address@hidden) wrote:
> On Wed, Nov 27, 2002 at 10:36:03PM +0100, Gert wrote:
> > Hi,
> > 
> > I have a question. Do you think it is possible to shorten the time pan
> > spends processing the newsgroup after getting the new headers? I am
> > subscribed to a binary newsgroup which has about 300.000 articles, and I
> > just clicked on the get new article headers menu item. It started
> > downloading, which it finished after a minute of 5, fetching the 90.000
> > new headers. That was 29 minutes ago (and yes, this problem is common
> > ;).
> > I don't quite know what it is supposed to be doing now (other then
> > consuming CPU cycles ;), but I doubt it is more then inserting
> > structures in a sorted linked list (/tree) ?
> 
> What does the status bar at the bottom say?

Nothing at all, the GUI won't update.

> Try attaching to the running pan process with gdb and hitting
> ctrl-c to pause it every few minutes, and get a backtrace.
> Where is Pan spending its time during these 30 minutes?
> 
> It will be practically impossible to fix this without helpers...

Got one here ;)
Ok,I just updated my headers, but this time (in gdb) it only took about
8 minutes. Main difference is that a lot of articles seemed to be
missing after I started pan. (My guess is it's a feature, pan removes
all messages from the window that aren't served by the newsserver? -
good feature anyways).
I did some backtraces during the CPU cycles, and continued to get traces
like:

#0  0x40524991 in nanosleep () from /lib/libc.so.6
#1  0x404787d2 in __pthread_timedsuspend_new () from /lib/libpthread.so.0
#2  0x40475286 in pthread_cond_timedwait_relative () from /lib/libpthread.so.0
#3  0x40475408 in pthread_cond_timedwait () from /lib/libpthread.so.0
#4  0x4046b7ab in _init () from /usr/lib/libgthread-2.0.so.0
#5  0x0807efb0 in gtk_widget_grab_focus ()
#6  0x4038d1d0 in g_static_private_free () from /usr/lib/libglib-2.0.so.0
#7  0x40475fa5 in pthread_start_thread () from /lib/libpthread.so.0
#8  0x40475fed in pthread_start_thread_event () from /lib/libpthread.so.0

Which I thing is just a worker thread. A backtrace on thread #1 (gdb
cmd "t 1") resulted in the following backtrace:

#0  0x404f88dd in memmove () from /lib/libc.so.6
#1  0x40364539 in g_ptr_array_remove_index () from /usr/lib/libglib-2.0.so.0
#2  0x40364641 in g_ptr_array_remove () from /usr/lib/libglib-2.0.so.0
#3  0x0805740a in gtk_widget_grab_focus ()
#4  0x08065a4c in gtk_widget_grab_focus ()
#5  0x0808b449 in gtk_widget_grab_focus ()
#6  0x40379f98 in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0
#7  0x40377a19 in g_get_current_time () from /usr/lib/libglib-2.0.so.0
#8  0x40378837 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9  0x40378c13 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#10 0x403792ef in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#11 0x400d000f in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x08074031 in gtk_widget_grab_focus ()
#13 0x4049d0bf in __libc_start_main () from /lib/libc.so.6

Perhaps this suggests a gtk bug? Do I even have the right thread (24 of
them are running or so)? My experience with gdb-ing threaded programs is
limited (make it zero ;)...

Hope it helps?

Gert
-- 
In my universe I'm perfectly normal.
It's not my fault you don't live in my universe.
        [read on slashdot]