wxTheApp->Yield() taking too long on Linux

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

wxTheApp->Yield() taking too long on Linux

Nathan Ridge

Hi,

I am experiencing a problem with wxTheApp->Yield() taking much
longer than needed on Linux.

My program is performing a time-consuming operation, which takes a
callback function that it calls to report the operation's progress.
The callback function I pass in updates a wxGauge, and calls
wxTheApp->Yield() to give the event loop the chance to process a
potential click on a "Cancel" button to interrupt the operation.

On Windows, each call to wxTheApp->Yield() takes about 0.1 ms,
which is quite reasonable.

On Linux, however, each call to wxTheApp->Yield() takes 20 ms on
average, though the time taken ranges from 10 to 100 ms. The
operation is calibrated so that the callback (and therefore
wxTheApp->Yield()) is called once for every one-pixel movement in
the wxGauge. As a result, the long Yield() times slow the
operation down to a crawl, so that more than 95% of the time is
being spent in Yield() rather than in the actual operation.

Do you know why wxTheApp->Yield() might be taking so long on Linux?
I do not recall having this problem with wx 2.8.

Thanks,
Nate
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: wxTheApp->Yield() taking too long on Linux

Vadim Zeitlin-4
On Mon, 13 Feb 2012 08:16:05 +0000 Nathan Ridge <[hidden email]> wrote:

NR> I am experiencing a problem with wxTheApp->Yield() taking much
NR> longer than needed on Linux.

 I don't know what are the reasons for this happening. There are a few
things done by wxGUIEventLoop::YieldFor() in src/gtk/evtloop.cpp but none
of them looks like it should be taking a long time. The most obvious
explanation would be that there are actually several/many events to process
and hence the time is spent in gtk_main_iteration() call from the loop but
this seems strange too. Anyhow, if you can profile this part of the code it
would be definitely helpful.

NR> As a result, the long Yield() times slow the operation down to a crawl,
NR> so that more than 95% of the time is being spent in Yield() rather than
NR> in the actual operation.

 Ouch. An obvious workaround is to avoid calling it more often than some
time interval but it would, of course, be nicer if it didn't take that
long.

NR> Do you know why wxTheApp->Yield() might be taking so long on Linux?
NR> I do not recall having this problem with wx 2.8.

 The main change since 2.8 that I can see is that we call
gdk_display_put_event() for the unprocessed events in side YieldFor() now.
However if you call just Yield() and not YieldFor() there shouldn't be any
of them if I understand the code correctly... But then again, I might not,
so profiling it would be very useful.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

> NR> Do you know why wxTheApp->Yield() might be taking so long on Linux?
> NR> I do not recall having this problem with wx 2.8.
>
> The main change since 2.8 that I can see is that we call
> gdk_display_put_event() for the unprocessed events in side YieldFor() now.
> However if you call just Yield() and not YieldFor() there shouldn't be any
> of them if I understand the code correctly... But then again, I might not,
> so profiling it would be very useful.

Using the "poor man's sampling profiler" [1], here are the most common
stack traces:

7 out of 19 interrupts:

#0  0xf738afb9 in ?? () from /usr/lib32/libpixman-1.so.0
#1  0xf73bc970 in ?? () from /usr/lib32/libpixman-1.so.0
#2  0xf7391a49 in ?? () from /usr/lib32/libpixman-1.so.0
#3  0xf73b7878 in ?? () from /usr/lib32/libpixman-1.so.0
#4  0xf73bf64a in ?? () from /usr/lib32/libpixman-1.so.0
#5  0xf73c086a in ?? () from /usr/lib32/libpixman-1.so.0
#6  0xf73b7523 in ?? () from /usr/lib32/libpixman-1.so.0
#7  0xf7392773 in ?? () from /usr/lib32/libpixman-1.so.0
#8  0xf73b959e in ?? () from /usr/lib32/libpixman-1.so.0
#9  0xf7392773 in ?? () from /usr/lib32/libpixman-1.so.0
#10 0xf73c49b3 in ?? () from /usr/lib32/libpixman-1.so.0
#11 0xf7392773 in ?? () from /usr/lib32/libpixman-1.so.0
#12 0xf73cb0d9 in ?? () from /usr/lib32/libpixman-1.so.0
#13 0xf7392773 in ?? () from /usr/lib32/libpixman-1.so.0
#14 0xf73b841f in pixman_image_composite () from /usr/lib32/libpixman-1.so.0
#15 0xf79fa4e4 in ?? () from /usr/lib32/libcairo.so.2
#16 0xf79fbcae in ?? () from /usr/lib32/libcairo.so.2
#17 0xf7a1f844 in ?? () from /usr/lib32/libcairo.so.2
#18 0xf7a04416 in ?? () from /usr/lib32/libcairo.so.2
#19 0xf7a06c4a in ?? () from /usr/lib32/libcairo.so.2
#20 0xf7a06f6a in ?? () from /usr/lib32/libcairo.so.2
#21 0xf7a033c7 in ?? () from /usr/lib32/libcairo.so.2
#22 0xf79e9f46 in ?? () from /usr/lib32/libcairo.so.2
#23 0xf79e3f6d in cairo_fill_preserve () from /usr/lib32/libcairo.so.2
#24 0xf79e3f92 in cairo_fill () from /usr/lib32/libcairo.so.2
#25 0xf71ca499 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#26 0xf71d88c2 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#27 0xf71d2d20 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#28 0xf7dad1ee in gtk_paint_box () from /usr/lib32/libgtk-x11-2.0.so.0
#29 0xf7d66f19 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#30 0xf7d67284 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#31 0xf7d2b424 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#32 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#33 0xf78b8252 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#34 0xf78cc5e6 in ?? () from /usr/lib32/libgobject-2.0.so.0
#35 0xf78cdc33 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#36 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#37 0xf7e58636 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#38 0xf7d2511b in gtk_main_do_event () from /usr/lib32/libgtk-x11-2.0.so.0
#39 0x081e1bf8 in wxgtk_main_do_event ()
#40 0xf7b9384b in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#41 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#42 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#43 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#44 0xf7bbcad4 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#45 0xf7b8ffa3 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#46 0xf7b91fbf in gdk_window_process_all_updates () from /usr/lib32/libgdk-x11-2.0.so.0
#47 0xf7b9203b in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#48 0xf7b6e358 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#49 0xf7807661 in ?? () from /lib32/libglib-2.0.so.0
#50 0xf78095e5 in g_main_context_dispatch () from /lib32/libglib-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#51 0xf780d2d8 in ?? () from /lib32/libglib-2.0.so.0
#52 0xf780d4b8 in g_main_context_iteration () from /lib32/libglib-2.0.so.0
#53 0xf7d25224 in gtk_main_iteration () from /usr/lib32/libgtk-x11-2.0.so.0
#54 0x081e1a1d in wxGUIEventLoop::YieldFor(long) ()

6 out of 19 interrupts:

#0  0xf7fdf430 in __kernel_vsyscall ()
#1  0xf7548c96 in *__GI___poll (fds=0xf75dcff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#2  0xf72c6d60 in ?? () from /usr/lib32/libxcb.so.1
#3  0xf72c72cb in ?? () from /usr/lib32/libxcb.so.1
#4  0xf72c7667 in xcb_writev () from /usr/lib32/libxcb.so.1
#5  0xf76f2d79 in _XSend () from /usr/lib32/libX11.so.6
#6  0xf76f33d9 in _XFlush () from /usr/lib32/libX11.so.6
#7  0xf76cb101 in XFlush () from /usr/lib32/libX11.so.6
#8  0xf7b9fcb4 in gdk_display_flush () from /usr/lib32/libgdk-x11-2.0.so.0
#9  0xf7b91f7a in gdk_window_process_all_updates () from /usr/lib32/libgdk-x11-2.0.so.0
#10 0xf7b9203b in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#11 0xf7b6e358 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#12 0xf7807661 in ?? () from /lib32/libglib-2.0.so.0
#13 0xf78095e5 in g_main_context_dispatch () from /lib32/libglib-2.0.so.0
#14 0xf780d2d8 in ?? () from /lib32/libglib-2.0.so.0
#15 0xf780d4b8 in g_main_context_iteration () from /lib32/libglib-2.0.so.0
#16 0xf7d25224 in gtk_main_iteration () from /usr/lib32/libgtk-x11-2.0.so.0
#17 0x081bf46d in wxGUIEventLoop::YieldFor(long) ()

2 out of 19 interrupts:

#0  0xf7fdf430 in __kernel_vsyscall ()
#1  0xf7548c96 in *__GI___poll (fds=0xf75dcff4, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#2  0xf72c6d60 in ?? () from /usr/lib32/libxcb.so.1
#3  0xf72c72cb in ?? () from /usr/lib32/libxcb.so.1
#4  0xf72c7667 in xcb_writev () from /usr/lib32/libxcb.so.1
#5  0xf76f2d79 in _XSend () from /usr/lib32/libX11.so.6
#6  0xf76df112 in ?? () from /usr/lib32/libX11.so.6
#7  0xf76df31a in XPutImage () from /usr/lib32/libX11.so.6
#8  0xf7a1c384 in ?? () from /usr/lib32/libcairo.so.2
#9  0xf7a1ff3d in ?? () from /usr/lib32/libcairo.so.2
#10 0xf7a046cb in ?? () from /usr/lib32/libcairo.so.2
#11 0xf79fa53a in ?? () from /usr/lib32/libcairo.so.2
#12 0xf79fbcae in ?? () from /usr/lib32/libcairo.so.2
#13 0xf7a1f844 in ?? () from /usr/lib32/libcairo.so.2
#14 0xf7a04416 in ?? () from /usr/lib32/libcairo.so.2
#15 0xf7a06c4a in ?? () from /usr/lib32/libcairo.so.2
#16 0xf7a06f6a in ?? () from /usr/lib32/libcairo.so.2
#17 0xf7a033c7 in ?? () from /usr/lib32/libcairo.so.2
#18 0xf79e9f46 in ?? () from /usr/lib32/libcairo.so.2
#19 0xf79e3f6d in cairo_fill_preserve () from /usr/lib32/libcairo.so.2
#20 0xf79e3f92 in cairo_fill () from /usr/lib32/libcairo.so.2
#21 0xf71ca499 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#22 0xf71d88c2 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#23 0xf71d2d20 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#24 0xf7dad1ee in gtk_paint_box () from /usr/lib32/libgtk-x11-2.0.so.0
#25 0xf7d66f19 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#26 0xf7d67284 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#27 0xf7d2b424 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#28 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#29 0xf78b8252 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#30 0xf78cc5e6 in ?? () from /usr/lib32/libgobject-2.0.so.0
#31 0xf78cdc33 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#32 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#33 0xf7e58636 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#34 0xf7d2511b in gtk_main_do_event () from /usr/lib32/libgtk-x11-2.0.so.0
#35 0x081e1bf8 in wxgtk_main_do_event ()
#36 0xf7b9384b in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#37 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#38 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#39 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#40 0xf7bbcad4 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#41 0xf7b8ffa3 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#42 0xf7b91fbf in gdk_window_process_all_updates () from /usr/lib32/libgdk-x11-2.0.so.0
#43 0xf7b9203b in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#44 0xf7b6e358 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#45 0xf7807661 in ?? () from /lib32/libglib-2.0.so.0
#46 0xf78095e5 in g_main_context_dispatch () from /lib32/libglib-2.0.so.0
#47 0xf780d2d8 in ?? () from /lib32/libglib-2.0.so.0
#48 0xf780d4b8 in g_main_context_iteration () from /lib32/libglib-2.0.so.0
#49 0xf7d25224 in gtk_main_iteration () from /usr/lib32/libgtk-x11-2.0.so.0
#50 0x081e1a1d in wxGUIEventLoop::YieldFor(long) ()

1 out of 19 interrupts:

#0  0xf7a40275 in ?? () from /usr/lib32/libcairo.so.2
#1  0xf7a09fda in ?? () from /usr/lib32/libcairo.so.2
#2  0xf7a0b34e in ?? () from /usr/lib32/libcairo.so.2
#3  0xf7a0b414 in ?? () from /usr/lib32/libcairo.so.2
#4  0xf79e1941 in ?? () from /usr/lib32/libcairo.so.2
#5  0xf79e239f in ?? () from /usr/lib32/libcairo.so.2
#6  0xf79fc3e3 in ?? () from /usr/lib32/libcairo.so.2
#7  0xf79f858e in ?? () from /usr/lib32/libcairo.so.2
#8  0xf79f4d66 in ?? () from /usr/lib32/libcairo.so.2
#9  0xf79f6c65 in ?? () from /usr/lib32/libcairo.so.2
#10 0xf7a071ac in ?? () from /usr/lib32/libcairo.so.2
#11 0xf7a0365e in ?? () from /usr/lib32/libcairo.so.2
#12 0xf79ea72e in ?? () from /usr/lib32/libcairo.so.2
#13 0xf79e3fcd in cairo_stroke_preserve () from /usr/lib32/libcairo.so.2
#14 0xf79e3ff2 in cairo_stroke () from /usr/lib32/libcairo.so.2
#15 0xf71c9eea in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#16 0xf71d88c2 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#17 0xf71d2d20 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#18 0xf7dad1ee in gtk_paint_box () from /usr/lib32/libgtk-x11-2.0.so.0
#19 0xf7d66f19 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#20 0xf7ec13f7 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#21 0xf78c5438 in g_cclosure_marshal_VOID__BOXED () from /usr/lib32/libgobject-2.0.so.0
#22 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#23 0xf78b8178 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#24 0xf78cc23a in ?? () from /usr/lib32/libgobject-2.0.so.0
#25 0xf78cddb4 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#26 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#27 0xf7e5d504 in gtk_widget_size_allocate () from /usr/lib32/libgtk-x11-2.0.so.0
#28 0x0812e7ba in size_allocate ()
#29 0xf78c5438 in g_cclosure_marshal_VOID__BOXED () from /usr/lib32/libgobject-2.0.so.0
#30 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#31 0xf78b8178 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#32 0xf78cc23a in ?? () from /usr/lib32/libgobject-2.0.so.0
#33 0xf78cddb4 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#34 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#35 0xf7e5d504 in gtk_widget_size_allocate () from /usr/lib32/libgtk-x11-2.0.so.0
#36 0x0812e7ba in size_allocate ()
#37 0xf78c5438 in g_cclosure_marshal_VOID__BOXED () from /usr/lib32/libgobject-2.0.so.0
#38 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#39 0xf78b8178 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#40 0xf78cc23a in ?? () from /usr/lib32/libgobject-2.0.so.0
#41 0xf78cddb4 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#42 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#43 0xf7e5d504 in gtk_widget_size_allocate () from /usr/lib32/libgtk-x11-2.0.so.0
#44 0xf7c65fb6 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#45 0xf78c5438 in g_cclosure_marshal_VOID__BOXED () from /usr/lib32/libgobject-2.0.so.0
#46 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#47 0xf78b8178 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#48 0xf78cc23a in ?? () from /usr/lib32/libgobject-2.0.so.0
#49 0xf78cddb4 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#50 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#51 0xf7e5d504 in gtk_widget_size_allocate () from /usr/lib32/libgtk-x11-2.0.so.0
#52 0xf7e702ee in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#53 0xf78c5438 in g_cclosure_marshal_VOID__BOXED () from /usr/lib32/libgobject-2.0.so.0
#54 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#55 0xf78b8252 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#56 0xf78cc23a in ?? () from /usr/lib32/libgobject-2.0.so.0
#57 0xf78cddb4 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#58 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#59 0xf7e5d504 in gtk_widget_size_allocate () from /usr/lib32/libgtk-x11-2.0.so.0
#60 0xf7c9a66f in gtk_container_resize_children () from /usr/lib32/libgtk-x11-2.0.so.0
#61 0xf7e7083c in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#62 0xf78c5dcc in g_cclosure_marshal_VOID__VOID () from /usr/lib32/libgobject-2.0.so.0
#63 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#64 0xf78b8252 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#65 0xf78cc5e6 in ?? () from /usr/lib32/libgobject-2.0.so.0
#66 0xf78cddb4 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#67 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#68 0xf7c9a70a in gtk_container_check_resize () from /usr/lib32/libgtk-x11-2.0.so.0
#69 0xf7c9a760 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#70 0xf7b6e358 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#71 0xf7807661 in ?? () from /lib32/libglib-2.0.so.0
#72 0xf78095e5 in g_main_context_dispatch () from /lib32/libglib-2.0.so.0
#73 0xf780d2d8 in ?? () from /lib32/libglib-2.0.so.0
#74 0xf780d4b8 in g_main_context_iteration () from /lib32/libglib-2.0.so.0
#75 0xf7d25224 in gtk_main_iteration () from /usr/lib32/libgtk-x11-2.0.so.0
#76 0x081e1a1d in wxGUIEventLoop::YieldFor(long) ()

1 out of 19 interrupts:

#0  0xf79e1cc7 in ?? () from /usr/lib32/libcairo.so.2
#1  0xf79f49fc in ?? () from /usr/lib32/libcairo.so.2
#2  0xf79e69c7 in ?? () from /usr/lib32/libcairo.so.2
#3  0xf79ea35c in ?? () from /usr/lib32/libcairo.so.2
#4  0xf79e3c6d in cairo_clip_preserve () from /usr/lib32/libcairo.so.2
#5  0xf79e3c92 in cairo_clip () from /usr/lib32/libcairo.so.2
#6  0xf71d8803 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#7  0xf71d2d20 in ?? () from /usr/lib/gtk-2.0/2.10.0/i486-pc-linux-gnu/engines/libmurrine.so
#8  0xf7dad1ee in gtk_paint_box () from /usr/lib32/libgtk-x11-2.0.so.0
#9  0xf7d66f19 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#10 0xf7d67284 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#11 0xf7d2b424 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#12 0xf78b68b9 in ?? () from /usr/lib32/libgobject-2.0.so.0
#13 0xf78b8252 in g_closure_invoke () from /usr/lib32/libgobject-2.0.so.0
#14 0xf78cc5e6 in ?? () from /usr/lib32/libgobject-2.0.so.0
#15 0xf78cdc33 in g_signal_emit_valist () from /usr/lib32/libgobject-2.0.so.0
#16 0xf78ce256 in g_signal_emit () from /usr/lib32/libgobject-2.0.so.0
#17 0xf7e58636 in ?? () from /usr/lib32/libgtk-x11-2.0.so.0
#18 0xf7d2511b in gtk_main_do_event () from /usr/lib32/libgtk-x11-2.0.so.0
#19 0x081e1bf8 in wxgtk_main_do_event ()
#20 0xf7b9384b in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#21 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#22 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#23 0xf7b937fa in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#24 0xf7bbcad4 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#25 0xf7b8ffa3 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#26 0xf7b91fbf in gdk_window_process_all_updates () from /usr/lib32/libgdk-x11-2.0.so.0
#27 0xf7b9203b in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#28 0xf7b6e358 in ?? () from /usr/lib32/libgdk-x11-2.0.so.0
#29 0xf7807661 in ?? () from /lib32/libglib-2.0.so.0
#30 0xf78095e5 in g_main_context_dispatch () from /lib32/libglib-2.0.so.0
#31 0xf780d2d8 in ?? () from /lib32/libglib-2.0.so.0
#32 0xf780d4b8 in g_main_context_iteration () from /lib32/libglib-2.0.so.0
#33 0xf7d25224 in gtk_main_iteration () from /usr/lib32/libgtk-x11-2.0.so.0
#34 0x081e1a1d in wxGUIEventLoop::YieldFor(long) ()

1 out of 19 interrupts:

#0  0x083436a1 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) ()
#1  0x08343774 in wxEvtHandler::TryHereOnly(wxEvent&) ()
#2  0x083437c4 in wxEvtHandler::ProcessEventLocally(wxEvent&) ()
#3  0x08343819 in wxEvtHandler::ProcessEvent(wxEvent&) ()
#4  0x0807cfbc in wxEvtHandler::TryParent (this=0xffffbff4, event=...) at /home/botond/Dev/Libraries/wxWidgets/include/wx/event.h:3344
#5  0x081af17d in wxWindowBase::TryAfter(wxEvent&) ()
#6  0x081b2fa2 in wxWindowBase::UpdateWindowUI(long) ()
#7  0x081ae2c7 in wxWindowBase::OnInternalIdle() ()
#8  0x081afd4a in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#9  0x081afd92 in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#10 0x081afd92 in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#11 0x0813cbb3 in wxFrame::SendIdleEvents(wxIdleEvent&) ()
#12 0x0814e745 in wxAppBase::ProcessIdle() ()
#13 0x081e1a52 in wxGUIEventLoop::YieldFor(long) ()

1 out of 19 interrupts:

#0  0x081afd30 in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#1  0x081afd92 in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#2  0x081afd92 in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#3  0x081afd92 in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#4  0x081afd92 in wxWindowBase::SendIdleEvents(wxIdleEvent&) ()
#5  0x0813cbb3 in wxFrame::SendIdleEvents(wxIdleEvent&) ()
#6  0x0814e745 in wxAppBase::ProcessIdle() ()
#7  0x081e1a52 in wxGUIEventLoop::YieldFor(long) ()


Do these tell you anything?

Note that the next function after the wxGUIEventLoop::YieldFor(long)
in all of the traces is the function in my code that calls wxTheApp->Yield().

Thanks,
Nate

[1] http://stackoverflow.com/questions/375913/what-can-i-use-to-profile-c-code-in-linux/378024#378024
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: wxTheApp->Yield() taking too long on Linux

Vadim Zeitlin-4
On Mon, 13 Feb 2012 21:53:44 +0000 Nathan Ridge <[hidden email]> wrote:

NR> > NR> Do you know why wxTheApp->Yield() might be taking so long on Linux?
NR> > NR> I do not recall having this problem with wx 2.8.
NR> >
NR> > The main change since 2.8 that I can see is that we call
NR> > gdk_display_put_event() for the unprocessed events in side YieldFor() now..
NR> > However if you call just Yield() and not YieldFor() there shouldn't be any
NR> > of them if I understand the code correctly... But then again, I might not,
NR> > so profiling it would be very useful.
NR>
NR> Using the "poor man's sampling profiler" [1], here are the most common
NR> stack traces:

 FWIW I really think you should follow the other advice on this page and
use callgrind + kcachegrind instead. It provides the same or better
functionality as ~$1000 products under Windows and is even simpler to use.
So, provided you have enough RAM to run your program under valgrind, you
really should try to use it.

NR> Do these tell you anything?

 It looks like repainting something takes a long time. Not sure what is
being repainted though nor why does it take longer than in 2.8.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re[2]: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

> NR> > NR> Do you know why wxTheApp->Yield() might be taking so long on Linux?
> NR> > NR> I do not recall having this problem with wx 2.8.
> NR> >
> NR> > The main change since 2.8 that I can see is that we call
> NR> > gdk_display_put_event() for the unprocessed events in side YieldFor() now..
> NR> > However if you call just Yield() and not YieldFor() there shouldn't be any
> NR> > of them if I understand the code correctly... But then again, I might not,
> NR> > so profiling it would be very useful.
> NR>
> NR> Using the "poor man's sampling profiler" [1], here are the most common
> NR> stack traces:
>
> FWIW I really think you should follow the other advice on this page and
> use callgrind + kcachegrind instead. It provides the same or better
> functionality as ~$1000 products under Windows and is even simpler to use.
> So, provided you have enough RAM to run your program under valgrind, you
> really should try to use it.

OK, I tried this. I'm not sure what exactly to look for in what kcachegrind
shows me, but the general picture I am seeing is that most of the time is
being spent in libcairo.so, libmurrine.so, and libpixman-1.so.

Is there something specific from the kcachegrind information that I could
post that would help diagnose the issue further?

Thanks,
Nate
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[4]: wxTheApp->Yield() taking too long on Linux

Vadim Zeitlin-4
On Tue, 14 Feb 2012 07:46:36 +0000 Nathan Ridge <[hidden email]> wrote:

NR> OK, I tried this. I'm not sure what exactly to look for in what kcachegrind
NR> shows me, but the general picture I am seeing is that most of the time is
NR> being spent in libcairo.so, libmurrine.so, and libpixman-1.so.

 So it does look like repainting takes a very long time. Not sure why is
this so, it doesn't look like a gauge should be that time consuming to
draw.

NR> Is there something specific from the kcachegrind information that I could
NR> post that would help diagnose the issue further?

 I'd like to know where is time spent by YieldFor(). Kcachegrind can show
you which parts of the total time are spent in the functions called by it,
perhaps you just didn't find the right view?

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re[4]: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

> NR> OK, I tried this. I'm not sure what exactly to look for in what kcachegrind
> NR> shows me, but the general picture I am seeing is that most of the time is
> NR> being spent in libcairo.so, libmurrine.so, and libpixman-1.so.
>
> So it does look like repainting takes a very long time. Not sure why is
> this so, it doesn't look like a gauge should be that time consuming to
> draw.
>
> NR> Is there something specific from the kcachegrind information that I could
> NR> post that would help diagnose the issue further?
>
> I'd like to know where is time spent by YieldFor(). Kcachegrind can show
> you which parts of the total time are spent in the functions called by it,
> perhaps you just didn't find the right view?

Here is a screenshot of the top entries of the "All Callees" view for YieldFor():
http://postimage.org/image/q3h2ef5sb/

Does this help diagnose the problem? Should I post more of it? (Is there some
more efficient way of getting the data out of kcachegrind than taking a
screenshot?)

Thanks,
Nate
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[6]: wxTheApp->Yield() taking too long on Linux

Vadim Zeitlin-4
On Wed, 15 Feb 2012 09:45:27 +0000 Nathan Ridge <[hidden email]> wrote:

NR> > I'd like to know where is time spent by YieldFor(). Kcachegrind can show
NR> > you which parts of the total time are spent in the functions called by it,
NR> > perhaps you just didn't find the right view?
NR>
NR> Here is a screenshot of the top entries of the "All Callees" view for YieldFor():
NR> http://postimage.org/image/q3h2ef5sb/

 Err, I don't even see YieldFor() here (did I just miss it). Perhaps it's
further below?

NR> Does this help diagnose the problem? Should I post more of it? (Is there some
NR> more efficient way of getting the data out of kcachegrind than taking a
NR> screenshot?)

 Could you please put (compressed) callgrind output somewhere? I could try
to use it here, I'm not sure if it's going to work well without matching
libraries/symbols but maybe it will?

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re[6]: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

> From: [hidden email]
>
> On Wed, 15 Feb 2012 09:45:27 +0000 Nathan Ridge <[hidden email]> wrote:
>
> NR> > I'd like to know where is time spent by YieldFor(). Kcachegrind can show
> NR> > you which parts of the total time are spent in the functions called by it,
> NR> > perhaps you just didn't find the right view?
> NR>
> NR> Here is a screenshot of the top entries of the "All Callees" view for YieldFor():
> NR> http://postimage.org/image/q3h2ef5sb/
>
> Err, I don't even see YieldFor() here (did I just miss it). Perhaps it's
> further below?

That view shows the callees *of* YieldFor, so naturally YieldFor itself isn't
on that list. Is that not the view you had in mind?

Thanks,
Nate
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

RE: Re[6]: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

----------------------------------------

> From: [hidden email]
>
> > From: [hidden email]
> >
> > On Wed, 15 Feb 2012 09:45:27 +0000 Nathan Ridge <[hidden email]> wrote:
> >
> > NR> > I'd like to know where is time spent by YieldFor(). Kcachegrind can show
> > NR> > you which parts of the total time are spent in the functions called by it,
> > NR> > perhaps you just didn't find the right view?
> > NR>
> > NR> Here is a screenshot of the top entries of the "All Callees" view for YieldFor():
> > NR> http://postimage.org/image/q3h2ef5sb/
> >
> > Err, I don't even see YieldFor() here (did I just miss it). Perhaps it's
> > further below?
>
> That view shows the callees *of* YieldFor, so naturally YieldFor itself isn't
> on that list. Is that not the view you had in mind?

That is, what is being shown is that 99.21% *of the time spent in YieldFor*
is spent in gtk_main_iteration, 55.0% is spent in wxEvtHandler::ProcessEvent,
and so on. At least, if I'm understanding it correctly..

Thanks,
Nate
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[8]: wxTheApp->Yield() taking too long on Linux

Vadim Zeitlin-4
In reply to this post by Nathan Ridge
On Wed, 15 Feb 2012 15:42:52 +0000 Nathan Ridge <[hidden email]> wrote:

NR> > NR> Here is a screenshot of the top entries of the "All Callees" view for YieldFor():
NR> > NR> http://postimage.org/image/q3h2ef5sb/
NR> >
NR> > Err, I don't even see YieldFor() here (did I just miss it). Perhaps it's
NR> > further below?
NR>
NR> That view shows the callees of YieldFor, so naturally YieldFor itself isn't
NR> on that list. Is that not the view you had in mind?

 Sorry, I misunderstood what it showed, I thought this was a full list of
functions called during the program execution. Anyhow, yes, this was
exactly what I had in mind, thanks.

 But the trouble is that I don't see anything obviously wrong here :-(
It's not really a surprise that a lot of time (11%) is spent in
wxWindow::SendIdleEvents(), we know that it can be a performance problem
and this is why we have wxIdleEvent::SetMode(wxIDLE_PROCESS_SPECIFIED).
But other than this I can only see potential inefficiencies due to event
handling complexities -- but this is not new, nor can we do anything about
this easily.

 I wonder if you still have your 2.8 version and if you could check if
there are any obvious differences with it?

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Re[8]: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

> Date: Wed, 15 Feb 2012 16:50:31 +0100
>
> On Wed, 15 Feb 2012 15:42:52 +0000 Nathan Ridge <[hidden email]> wrote:
>
> NR> > NR> Here is a screenshot of the top entries of the "All Callees" view for YieldFor():
> NR> > NR> http://postimage.org/image/q3h2ef5sb/
> NR> >
> NR> > Err, I don't even see YieldFor() here (did I just miss it). Perhaps it's
> NR> > further below?
> NR>
> NR> That view shows the callees of YieldFor, so naturally YieldFor itself isn't
> NR> on that list. Is that not the view you had in mind?
>
> Sorry, I misunderstood what it showed, I thought this was a full list of
> functions called during the program execution. Anyhow, yes, this was
> exactly what I had in mind, thanks.
>
> But the trouble is that I don't see anything obviously wrong here :-(
> It's not really a surprise that a lot of time (11%) is spent in
> wxWindow::SendIdleEvents(), we know that it can be a performance problem
> and this is why we have wxIdleEvent::SetMode(wxIDLE_PROCESS_SPECIFIED).
> But other than this I can only see potential inefficiencies due to event
> handling complexities -- but this is not new, nor can we do anything about
> this easily.

Why are idle events being sent from Yield()? Isn't the whole idea of Yield() to
process any *pending* events, and then return control to the caller, while idle
events are generated when there is nothing else to do?

> I wonder if you still have your 2.8 version and if you could check if
> there are any obvious differences with it?

I have a binary of it, compiled without debug information. I'm not sure whether
any useful information can be gotten out of that, but I can try.

Regards,
Nate
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

RE: Re[8]: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

> > I wonder if you still have your 2.8 version and if you could check if
> > there are any obvious differences with it?
>
> I have a binary of it, compiled without debug information. I'm not sure whether
> any useful information can be gotten out of that, but I can try.

In trying this, I realized that the problem is actually not 2.8 vs. 2.9, it's
sitting directly at my Linux machine vs. being logged into it via NX [1] ...

Both 2.8 and 2.9 perform fine when I am sitting directly at my Linux
machine (actually, there is still a slowdown from 2.8 to 2.9, but it's much
slighter, and it may not be a wxWidgets issue - I'd have to investigate more).

It is when I am logged into my Linux machine via NX that I experience
the orders-of-magnitude slowdown in wxYield() for 2.9 (I haven't tried
with 2.8 yet, I will try later today).

Do you know why wxYield() might be taking so much longer when I am
connected over NX? Generally GUIs  are a bit slower over NX than when
sitting at the machine, but not orders-of-magnitude slower...

Thanks,
Nate

[1] http://www.nomachine.com/
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: wxTheApp->Yield() taking too long on Linux

Robin Dunn
On 2/15/12 11:19 AM, Nathan Ridge wrote:

>
>>> I wonder if you still have your 2.8 version and if you could check if
>>> there are any obvious differences with it?
>>
>> I have a binary of it, compiled without debug information. I'm not sure whether
>> any useful information can be gotten out of that, but I can try.
>
> In trying this, I realized that the problem is actually not 2.8 vs. 2.9, it's
> sitting directly at my Linux machine vs. being logged into it via NX [1] ...
>
> Both 2.8 and 2.9 perform fine when I am sitting directly at my Linux
> machine (actually, there is still a slowdown from 2.8 to 2.9, but it's much
> slighter, and it may not be a wxWidgets issue - I'd have to investigate more).
>
> It is when I am logged into my Linux machine via NX that I experience
> the orders-of-magnitude slowdown in wxYield() for 2.9 (I haven't tried
> with 2.8 yet, I will try later today).
>
> Do you know why wxYield() might be taking so much longer when I am
> connected over NX? Generally GUIs  are a bit slower over NX than when
> sitting at the machine, but not orders-of-magnitude slower...

If there is lots more back-and-forth communication between the
application and the X server in 2.9 than there was in 2.8, then that
difference can be greatly magnified when the X server is not on the same
machine as the application.  Do typical GTK applications show a similar
level of slowdown between running local and running remotely?  If not
then there is probably something in wxGTK that could be done in a more
efficient way, but I wouldn't even know where to start looking for
something like that.


--
Robin Dunn
Software Craftsman
http://wxPython.org

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

RE: wxTheApp->Yield() taking too long on Linux

Nathan Ridge

> From: [hidden email]
>
> On 2/15/12 11:19 AM, Nathan Ridge wrote:
> >
> >>> I wonder if you still have your 2.8 version and if you could check if
> >>> there are any obvious differences with it?
> >>
> >> I have a binary of it, compiled without debug information. I'm not sure whether
> >> any useful information can be gotten out of that, but I can try.
> >
> > In trying this, I realized that the problem is actually not 2.8 vs. 2.9, it's
> > sitting directly at my Linux machine vs. being logged into it via NX [1] ...
> >
> > Both 2.8 and 2.9 perform fine when I am sitting directly at my Linux
> > machine (actually, there is still a slowdown from 2.8 to 2.9, but it's much
> > slighter, and it may not be a wxWidgets issue - I'd have to investigate more).
> >
> > It is when I am logged into my Linux machine via NX that I experience
> > the orders-of-magnitude slowdown in wxYield() for 2.9 (I haven't tried
> > with 2.8 yet, I will try later today).
> >
> > Do you know why wxYield() might be taking so much longer when I am
> > connected over NX? Generally GUIs are a bit slower over NX than when
> > sitting at the machine, but not orders-of-magnitude slower...
>
> If there is lots more back-and-forth communication between the
> application and the X server in 2.9 than there was in 2.8, then that
> difference can be greatly magnified when the X server is not on the same
> machine as the application. Do typical GTK applications show a similar
> level of slowdown between running local and running remotely? If not
> then there is probably something in wxGTK that could be done in a more
> efficient way, but I wouldn't even know where to start looking for
> something like that.

I tried with 2.8 over NX, it's just as slow as 2.9 over NX. So it really
is just an issue of NX vs. direct access, as opposed to 2.8 vs. 2.9.
Apologies for jumping to incorrect conclusions earlier.

With regards to the behaviour with NX, I guess it makes sense that each
update of the wxGauge requires a round-trip from the server to the client
and back, and therefore each call to wxYield() takes on the order of
10-20 ms (whereas when using the program directly on the machine it takes
on the order of 0.1-0.2 ms).

I have not experienced this problem with other GTK applications, but that
could just be because they do not make UI updates as frequently as I was
updating my wxGauge (once per pixel increment).

I guess the lesson to take away is to avoid too-frequent UI updates if
the program might be used over a remote connection.

Thanks Vadim and Robin for your help!

Regards,
Nate
     

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users