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

[Tristan Van Berkom]

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