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

Well I should first point out that my 2 second lag is more like 1 second
now--not quite sure why.

With the patch (I pulled master 4 or 5 days ago) I don't see
any noticeable difference. I'm testing with a GtkBox with a GtkButton and
GtkLabel as the children and clicking back and forth between them.

On Tue, Dec 27, 2011 at 7:13 AM, Micah Carrick <[email protected]> wrote:

> I'm going to give it a go sometime today.
>
>
> On Thu, Dec 22, 2011 at 10:53 PM, Tristan Van Berkom <
> [email protected]> 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
>> <[email protected]> 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
>> > <[email protected]> wrote:
>> >> On Thu, Dec 22, 2011 at 1:39 AM, Micah Carrick <[email protected]>
>> 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 <[email protected]
>> >
>> >>> 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
>> >>>> <[email protected]> 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 <[email protected]>
>> >>>>> 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 <
>> [email protected]>
>> >>>>> > 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
>> >>>>> >> <[email protected]> wrote:
>> >>>>> >>>
>> >>>>> >>> On Wed, Dec 21, 2011 at 4:10 AM, Matej Nanut <
>> [email protected]>
>> >>>>> >>> 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 <[email protected]>
>> >>>>> >>> > 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  -  [email protected]
>> >>>>> >>> >> http://lists.ximian.com/mailman/listinfo/glade-users
>> >>>>> >>> >>
>> >>>>> >>> >
>> >>>>> >>> >
>> >>>>> >>> > _______________________________________________
>> >>>>> >>> > Glade-users maillist  -  [email protected]
>> >>>>> >>> > http://lists.ximian.com/mailman/listinfo/glade-users
>> >>>>> >>> >
>> >>>>> >>>
>> >>>>> >>>
>> >>>>> >
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>>     Green Tackle - Environmentally Friendly Fishing Tackle
>> >>>>     www.GreenTackle.com
>> >>>>
>> >>>>      Email: [email protected]
>> >>>>      Phone: 971.270.2206
>> >>>>      Toll Free: 877.580.9165
>> >>>>      Fax: 503.946.3106
>> >>>>
>> >>>>
>> >>>
>>
>
>

_______________________________________________
Glade-users maillist  -  [email protected]
http://lists.ximian.com/mailman/listinfo/glade-users