Performance Issue with Gtk.jl

General Usage
1

Hi,

I have a performance issue that may be linked to Gtk.jl. My application needs 30 sec to start up the first time and profiling tells me that most of the time is spend in inference. The app is a little larger so that some dynamic typing (e.g. when using Dicts) cannot be avoided.

The inference call is triggered from this line in Gtk.jl

https://github.com/JuliaGraphics/Gtk.jl/blob/master/src/GLib/signals.jl#L11

it involves a cfunction so it may be linked to Performance regression of Cuba.jl on Julia 0.6 which I however do not really understand. @yuyichao do you know if there is an issue with the Gtk.jl code?

2

@tim.holy: Have you observed performance issues with the “low-level” signal-connect interface of Gtk.jl? That which uses cfunction? The other “high-level” interface is much faster during signal-connect but it has a serious performance hit, when the signal is fired the first time.

3

@jameson: Do you have an idea why signal_connect low level can be that slow?

I don’t see this massive performance issue when I execute the code regularly (i.e. not in a callback)

4

… without having any details, but

“serious performance hit, when the signal is fired the first time”
and
“me that most of the time is spend in inference.”

sounds like, we see this delay as compilation time of the code. In one place as JIT at the time the signal connect is done OR at the time the code is called the first time and not available as compiled.
I did see similar effects when i worked/tested GUIs with Gtk.jl but my callbacks usually were rather short functions that only update data.

Can you somehow make an example available?

5

Unfortunately this is a pretty big code base, that I cannot make public available. Small callbacks are no issues but here I have the feeling that inference takes a lot longer than it would when I call the function not in a callback.

6

I would love to get rid of type unstable code. But if one implements a larger Application with config files, one starts to have Dicts that are inherently type unstable. I use TOML which gives me Dicts

7

But maybe that’s already the full example:

  • GUI with Gtk.jl (window and a button)
  • connect button-press with a call to ‘read_in_configuration’
  • read_in_configuration calls TOML and uses random data
    ?
8

I have now a minimal example that shows the issue:

using Gtk.ShortNames
ENV["WINSTON_OUTPUT"] = :gtk
using Winston

box = Box(:v)
b = Button("test")
push!(box,b)
c = Canvas()
push!(box,c)
setproperty!(box,:expand,c,true)
w = Window(box,"Test")

function callback(widgetptr::Ptr, m::Ptr)
  p = Winston.plot(1:5)
  display(c,p)
  return nothing
end

@time signal_connect(callback, b, "clicked", Void, (), false, C_NULL )

showall(w)

Here, the signal_connect requires more than 10 seconds on julia 0.6.0 and about 5 seconds on julia 0.6.3.

@jameson: You have proposed using a schedule in the callback

using Gtk.ShortNames
ENV["WINSTON_OUTPUT"] = :gtk
using Winston

box = Box(:v)
b = Button("test")
push!(box,b)
c = Canvas()
push!(box,c)
setproperty!(box,:expand,c,true)
w = Window(box,"Test")

function callback(widgetptr::Ptr, m::Ptr)
  @schedule begin
    p = Winston.plot(1:5)
    display(c,p)
  end
  return nothing
end

@time signal_connect(callback, b, "clicked", Void, (), false, C_NULL )

showall(w)

Now the signal connection is faster (0.6 sec) but when I click the button it requires 5 seconds. And the UI is frozen during that time.

If you or anybody else has an idea how to solve this it would be great. I suppose that the new multi-threaded task manager will solve the UI freeze?
But this still does not solve the Winston slowness ( https://github.com/JuliaLang/julia/issues/27083) which was fast once upon a time. Will be very interesting how fast Winston is on Julia 0.7 (https://github.com/JuliaGraphics/Winston.jl/pull/292)