[Glade-users] [glade-users] Glade 3.10.0 is running a bit slow

Tristan Van Berkom tristan.van.berkom at gmail.com
Fri Dec 23 01:53:51 EST 2011 

Ok I discussed this with Benjamin Otte on irc and made sure that other GTK+
devs are aware of this problem.

I'm not convinced that people are taking performance issues seriously enough
but currently I don't have time to intervene myself.

Benjamin suggested I try a workaround, it does nothing for me here but then
again, I dont run the full blown adwaita theme so that should explain it.

The problem is that GtkBox goes and resets the css any time one of
it's children are shown or hidden, this is because the children's style's
*might* change depending on what position they are in their siblings.

Not only does this reset the style but also queues a resize, totally
trampling over the size request cache which I worked so hard to optimize :-(

So the suggested workaround is to use a GtkGrid instead of a GtkBox,
hopefully GtkGrid will not be so evil to our editor children, I'm attaching
the patch here which should safely apply to Glade 3.10 (or master).

Can someone with the Adwaita theme and 2 second horrible bug available
to them... try this patch for me and tell me if they see any improvement ?

Thanks for your cooperation in this.

Cheers,
    -Tristan

On Thu, Dec 22, 2011 at 2:36 AM, Tristan Van Berkom
<tristan.van.berkom at gmail.com> wrote:
> Ok, made the same mistake myself, somehow the last mail missed the list...
>
> Here it the response:
>
> On Thu, Dec 22, 2011 at 2:36 AM, Tristan Van Berkom
> <tristan.van.berkom at gmail.com> wrote:
>> On Thu, Dec 22, 2011 at 1:39 AM, Micah Carrick <micah at quixotix.com> wrote:
>>> I should actually point out that turning off the default GNOME 3 doesn't
>>> "fix" the issue, it just makes the lag less significant. Sounds like what
>>> you experienced Tristan--about half a second.
>>
>> Yes, that needs to be looked into as well.
>>
>> Glade does make a slight abstraction for sending events to
>> widget adaptors instead of sending them directly to widgets,
>> I don't believe that can be related (actually, this operation occurs
>> even for every pointer motion event and does not seem to
>> incur any lag).
>>
>> The rest of the slowness involved might very well be related
>> to GTK+ geometry management, i.e. time spent in the
>> _gtk_container_idle_sizer().
>>
>> As for the labels in the editor, their sizes should be cached
>> as of the first time the editor is shown, and half of the request
>> cycle can be triggered again if ever the width of the editor is
>> adjusted (should not be related).
>>
>> It's possible that for some reason, either in GTK+ or possibly
>> Glade could work around this better... that possibly the size
>> request cache could be getting 'trampled' so to speak and
>> needlessly re-requested for the sake of a gtk_widget_show().
>>
>> The process of updating the current widget class editor is
>> really just a matter of:
>>  a.) unsetting the currently selected widget in the editor
>>  b.) hiding the current class editor (which is packed in a vbox
>>        inside the notebook page)
>>  c.) showing the new class editor (since it is cached, it's already
>>       a child of the same vbox).
>>  d.) running through the property editors on that page and updating
>>       their current values.
>>
>> So, for the most part, around 75% of the time spent on this operation
>> can be attributed to the css class lookup proceedure... which probably
>> needs work in terms of caching previous results... these lookups should not
>> be done by GTK+ unless one of the deciding factors (widget name,
>> widget class, style change) actually change.
>>
>> Perhaps that code caches things properly but maybe erronously clears
>> the cache for the sake of a gtk_widget_hide() or gtk_widget_show()...
>>
>> Cheers,
>>              -Tristan
>>
>>
>>>
>>> Also, I posted my last message with the wrong email, not sure if it went
>>> through. It's shown below:
>>>
>>>
>>> On Wed, Dec 21, 2011 at 8:23 AM, Micah Carrick <micah at greentackle.com>
>>> wrote:
>>>>
>>>> Ding ding ding ding!
>>>>
>>>> I'm using GNOME 3 on Fedora 16 with the GNOME 3 default theme
>>>> Adwaita. When I switch the GTK+ theme to Raleigh using Gnome Tweak Tool the
>>>> problem is goes away. I'm not up to speed on how themes work in gtk+ 3 but I
>>>> believe Raleigh does not use a theme engine.
>>>>
>>>> On Wed, Dec 21, 2011 at 6:17 AM, Tristan Van Berkom
>>>> <tristan.van.berkom at gmail.com> wrote:
>>>>>
>>>>> Thanks !
>>>>>
>>>>> I loaded up the file you sent and it appears that most of the time can
>>>>> be tracked
>>>>> down to:
>>>>>  a.) Glade handling events, which results in showing a hidden editor
>>>>> page in the
>>>>>       GladeEditor widget...
>>>>>  b.) When looking at the callees of glade_widget_event() one notes that
>>>>>        most of the time spent in there is spent in
>>>>> gtk_css_provider_get_style()
>>>>>
>>>>> Possibly the problem is around resolving things that should probably
>>>>> already
>>>>> have been cached the first time around (i.e., how come we spend time
>>>>> searching
>>>>> and matching css styles for the widgets in the editor if they've been
>>>>> created
>>>>> at least once ?)
>>>>>
>>>>> One thing I have never tried personally, is a GTK+ 3 installation in /usr
>>>>> and
>>>>> a theme installed, is this why I am not getting such bad performance
>>>>> issues ?
>>>>>
>>>>>
>>>>> Is your test case built into /usr  ? maybe that doesnt matter... do you
>>>>> get
>>>>> the ugly default native GTK+ theme or are you picking up some kind of
>>>>> elaborate and beautiful theme while running Glade ?
>>>>>
>>>>> If so, can you try running Glade in a naked environment, with no fancy
>>>>> css applied and report back if the problem persists ? (or if it's less
>>>>> bad ?)
>>>>>
>>>>>
>>>>> Thanks alot for your help, I'm trying a GTK+ master build now to see
>>>>> if this is a possible regression... I havent been paying attention to
>>>>> GTK+ releases lately... maybe everyone is running something more
>>>>> recent than 3.3.3.
>>>>>
>>>>> Cheers,
>>>>>          -Tristan
>>>>>
>>>>>
>>>>> On Wed, Dec 21, 2011 at 9:06 AM, Micah Carrick <micah at quixotix.com>
>>>>> wrote:
>>>>> > Hey, I'm going to attach my callgrind output in case one of y'all know
>>>>> > what
>>>>> > you are doing better than I do. I started glade with`
>>>>> > --instr-atstart=no`,
>>>>> > added a button and a label to the window, and then turned it on with
>>>>> > `callgrind_control -i on`. I then selected a different widget and
>>>>> > turned it
>>>>> > off with `callgrind_control -i off`.
>>>>> >
>>>>> > I don't really know what I'm looking for the KCacheGrind just yet and I
>>>>> > don't have any more time to dig around today, but all these graphs ans
>>>>> > such
>>>>> > look pretty awesome.
>>>>> >
>>>>> >
>>>>> > On Tue, Dec 20, 2011 at 2:44 PM, Micah Carrick <micah at quixotix.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> I've got 4GB RAM and a dual core AMD64... plenty fast. I have a lag of
>>>>> >> 1.5
>>>>> >> - 2 seconds based on the very accurate and scientific "one
>>>>> >> mississippi, two
>>>>> >> mississippi..." approach. ;)
>>>>> >>
>>>>> >> I'll see if I can tinker with valgrind sometime in the next week or so
>>>>> >> if
>>>>> >> I have time.
>>>>> >>
>>>>> >> On Tue, Dec 20, 2011 at 1:53 PM, Tristan Van Berkom
>>>>> >> <tristan.van.berkom at gmail.com> wrote:
>>>>> >>>
>>>>> >>> On Wed, Dec 21, 2011 at 4:10 AM, Matej Nanut <matejnanut at gmail.com>
>>>>> >>> wrote:
>>>>> >>> > I've asked the same question here about a month (?) ago, and there
>>>>> >>> > was
>>>>> >>> > no
>>>>> >>> > definite answer,
>>>>> >>>
>>>>> >>> I just tried building a few versions here, and I have pretty much the
>>>>> >>> same lag
>>>>> >>> from GTK+ 3.0.9 to GTK+ 3.3.3, I havent tried any versions before
>>>>> >>> 3.0.9
>>>>> >>> or
>>>>> >>> after 3.3.3.
>>>>> >>>
>>>>> >>> I have a very old laptop here (about 5yrs old and chugging along,
>>>>> >>> every
>>>>> >>> second time I power her up she decides to find the operating
>>>>> >>> system...
>>>>> >>> and
>>>>> >>> grub happily shows up).
>>>>> >>>
>>>>> >>> Running 64bit linux here, with this processor:
>>>>> >>>   AMD Turion(tm) 64 X2 Mobile Technology TL-58
>>>>> >>>
>>>>> >>> Its dual core, each of them dishing out about 800Mhz.
>>>>> >>>
>>>>> >>> Admittedly selecting a new widget is annoyingly slow,
>>>>> >>> probably around half a second or a bit more, just enough
>>>>> >>> to make you feel annoyed, definitely nowhere close to
>>>>> >>> a 2 second lag.
>>>>> >>>
>>>>> >>> Currently I'm really busy with other things and can't be
>>>>> >>> bothered... so I'm looking to you guys to profile it and find
>>>>> >>> out where is the bottle neck, where are we spending the
>>>>> >>> majority of this time ?
>>>>> >>>
>>>>> >>> In size requests ? is it a silly Glade bug ?
>>>>> >>>
>>>>> >>> I recommend valgrind with the cachegrind tool, output
>>>>> >>> is quite pretty when viewed with kcachegrind.
>>>>> >>>
>>>>> >>> And it doesnt require hacking your kernel like other modern
>>>>> >>> profilers do...
>>>>> >>>
>>>>> >>> Cheers,
>>>>> >>>              -Tristan
>>>>> >>>
>>>>> >>> > apart from it probably being GTK's and not Glade's fault.
>>>>> >>> > I just opted to actually coding my interfaces until this gets
>>>>> >>> > corrected.
>>>>> >>> >
>>>>> >>> > Sorry I couldn't be of much help,
>>>>> >>> > Matej
>>>>> >>> >
>>>>> >>> > On 20 December 2011 20:03, Micah Carrick <micah at quixotix.com>
>>>>> >>> > wrote:
>>>>> >>> >>
>>>>> >>> >> I've seen a few other people mentioning this, but, I can't find
>>>>> >>> >> any
>>>>> >>> >> bugs
>>>>> >>> >> or information. What I'm seeing is that when you select from one
>>>>> >>> >> widget to
>>>>> >>> >> another (either in the editor or the inspector) the UI blocks for
>>>>> >>> >> about 2
>>>>> >>> >> full seconds. This only happens when selecting a widget of a
>>>>> >>> >> different
>>>>> >>> >> type
>>>>> >>> >> than the one currently selected (eg. selecting a GtkButton and
>>>>> >>> >> then
>>>>> >>> >> another
>>>>> >>> >> GtkButton is fast, but then selecting a GtkEntry is slow).
>>>>> >>> >>
>>>>> >>> >> Any insights?
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >>
>>>>> >>> >> _______________________________________________
>>>>> >>> >> Glade-users maillist  -  Glade-users at lists.ximian.com
>>>>> >>> >> http://lists.ximian.com/mailman/listinfo/glade-users
>>>>> >>> >>
>>>>> >>> >
>>>>> >>> >
>>>>> >>> > _______________________________________________
>>>>> >>> > Glade-users maillist  -  Glade-users at lists.ximian.com
>>>>> >>> > http://lists.ximian.com/mailman/listinfo/glade-users
>>>>> >>> >
>>>>> >>>
>>>>> >>>
>>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>     Green Tackle - Environmentally Friendly Fishing Tackle
>>>>     www.GreenTackle.com
>>>>
>>>>      Email: micah at greentackle.com
>>>>      Phone: 971.270.2206
>>>>      Toll Free: 877.580.9165
>>>>      Fax: 503.946.3106
>>>>
>>>>
>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: try-work-around.patch
Type: text/x-patch
Size: 955 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/glade-users/attachments/20111223/2c2d6242/attachment.bin

More information about the Glade-users mailing list