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

Tristan Van Berkom tristan.van.berkom at gmail.com
Wed Dec 21 12:36:59 EST 2011 

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
>>>
>>>
>>

More information about the Glade-users mailing list