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

Micah Carrick micah at quixotix.com
Tue Dec 27 10:13:53 EST 2011 

I'm going to give it a go sometime today.

On Thu, Dec 22, 2011 at 10:53 PM, Tristan Van Berkom <
tristan.van.berkom at gmail.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/glade-users/attachments/20111227/d72f0a3a/attachment-0001.html

More information about the Glade-users mailing list