GNOME Bugzilla – Bug 157805
gtk_label_set_text severe performance problem
Last modified: 2009-01-19 20:19:05 UTC
Create a program using numerous (at least 10) GTK_LABELS. Update them with a small amount of text (4-5 charactors) at a 20-30 times per second rate. CPU usage will be steady and VERY high (30-90% on a athlon 1.2Ghz)
Please provide a small, selfcontained testcase showing the problem. I wonder why you need to update 10 labels at a rate of 30 times per second. The user will have a hard time to keep up reading what you flash at him...
Created attachment 35106 [details] testcase file to show pu usage for updating labels compile with: gcc -o testcase testcase.c `pkg-config gtk+-2.0 --cflags --libs`
Sorry if this is unconstructive, but I'm sick of hearing people telling such things as "I wonder why you need to update 10 labels at a rate of 30 times per second". We're doing a multimedia application where the user has to monitor many values, bar. Most other toolkits are handling that fine AFAIK. Right now our application is badly hurt due to GTK performance problems and we can't find any proper answer, FAQ, workaround related to that. Thanks for your work guys.
Seeing 5-11% CPU usage on a 2.8GHz system. Adding perf keyword.
Each time you change a label's text, you cause the whole window to be resized. Have you run a profiler on this? Sysprof would be able to tell you what part of GTK+ is causing the slowdown, or whether it is the X server.
Created attachment 59371 [details] Gzipped log from Sysprof Note how gtk_widget_region_intersect() is the top time consumer.
What is the "draw-border" style property? We query it on every expose of a no-window widget, which involves walking the type system...
Federico, draw-border was added by Owen last spring to allow widgets to draw outside their allocation. One thing that could be optimized here is to avoid using the generic style_get() getter since we know that draw-border is a style property of GtkWidget, so there is no real reason to force g_param_spec_pool_lookup to loop over the type anchestry and do multiple hash table lookups along the way. Instead we could just have a get_draw_border() which would do pspec = g_param_spec_pool_lookup (style_property_spec_pool, "draw-border", GTK_TYPE_WIDGET, FALSE); to get quickly at the pspec. If style property lookup turns out to be a performance problem, we might also want to look at other frequently used style properties like focus-line-width, and add nongeneric getters for them.
To get some idea how often we look up style properties, here are some numbers from testgtk --bench all: 2 peek style prop allow-rules 2 peek style prop child-displacement-x 2 peek style prop child-displacement-y 2 peek style prop tab-overlap 3 peek style prop expander-spacing 4 peek style prop message-border 4 peek style prop use-separator 5 peek style prop expander-size 6 peek style prop slider-length 6 peek style prop tab-curvature 6 peek style prop toggle-spacing 11 peek style prop even-row-color 16 peek style prop internal-padding 25 peek style prop value-spacing 26 peek style prop fixed-slider-length 26 peek style prop min-slider-length 27 peek style prop action-area-border 27 peek style prop button-spacing 27 peek style prop content-area-border 27 peek style prop has-backward-stepper 27 peek style prop has-forward-stepper 27 peek style prop has-secondary-backward-stepper 27 peek style prop has-secondary-forward-stepper 34 peek style prop handle-size 34 peek style prop horizontal-padding 65 peek style prop button-relief 78 peek style prop scrollbar-spacing 80 peek style prop child-internal-pad-x 80 peek style prop child-internal-pad-y 80 peek style prop child-min-height 80 peek style prop child-min-width 99 peek style prop default-outside-border 164 peek style prop shadow-type 262 peek style prop arrow-displacement-x 262 peek style prop arrow-displacement-y 262 peek style prop slider-width 262 peek style prop stepper-size 262 peek style prop stepper-spacing 262 peek style prop trough-border 264 peek style prop space-size 308 peek style prop indicator-size 308 peek style prop indicator-spacing 386 peek style prop vertical-separator 396 peek style prop horizontal-separator 762 peek style prop interior-focus 3002 peek style prop inner-border 3101 peek style prop default-border 4299 peek style prop focus-padding 5263 peek style prop focus-line-width 8079 peek style prop draw-border
Created attachment 61393 [details] [review] a patch the patch tries the two optimizations outlined above: 1) avoid draw-border overhead, by maintaining and using 2 per-widget flags "I have no draw-border" and "My draw-border is contained in my parents'" 2) add non-generic getters for the most commonly used style properties: draw-border, the border properties in gtkbutton, and gtkwidget focus style properties Unfortunately, I could not see a significant performance difference in gtkperf, when using these.
Do you have a profile when the patch is in place? That may help explain why there is no difference in performance.
no, I don't. Sorry.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!