Linux X11: Slow window creation

[kimsnj]

I am experiencing a very slow window creation on a linux laptop.
I used following snippet to test it:

extern crate winit;

fn main() {
    let events_loop = winit::EventsLoop::new();

    let _window = winit::WindowBuilder::new()
        .with_title("A fantastic window!")
        .build(&events_loop)
        .unwrap();
}

And as a result of time:

> time target/release/examples/open

real	0m2.269s
user	0m0.005s
sys	0m0.005s

My laptop is running Ubuntu Gnome 16.04 with X11.
It has an Intel i7-4810MQ and is using the integrated GPU.

I created a flamegraph here (doesn't seem to be possible to include directly the svg as attachement).

Any clue on where the issue might come from / how to dig deeper ?
Thanks in advance for your help.

[francesca64]

Thanks for reporting this!

Before looking into this more, 2 things:

1. What version of winit are you using?
2. Could you try generating the flamegraph from a debug build? I assume there'd be more symbol names that way.

[kimsnj]

I reported the issue after cloning from master directly.
I since bisected git history to see if previous versions had the same issue.
It appears that the slowdown was introduced between v0.15.1 and v0.16.1 and more specifically by commit DPI for everyone

Time before: 40ms
Time after: 2s
I'v added flamegraphs before / after in this gist

[chrisduerr]

Possible duplicate of #682?

[kimsnj]

The issue occurs for me even with no external monitor is plugged to the laptop.

But looking at the latest comment from @ti-mo in above issue. I tried:

> time xrandr > /dev/null

real	0m1.956s
user	0m0.000s
sys	0m0.004s

So I guess it does share a similar root cause. (though in ti-mo's case, xrandr is actually pretty fast… )

[goddessfreya]

@kimsnj The flame graph doesn't list fn names for a lot of things...

Can I get valgrind --tool=callgrind --dump-instr=yes --collect-jumps=yes --simulate-cache=yes <path to executable> instead?

Also, if it is a duplicate of #682, try my pr #801

[Osspial]

Now that #801's been merged, is this still an issue?

[kimsnj]

Hi,

I don't have access anymore to my previous work laptop that demonstrated the behavior.
On the current one (and with the latest version), running alacritty -e false takes ~100ms.

So I guess this issue can be closed as I cannot provide more leads as to what happened on the other setup.

Thank you all for you help and for this project :)