Performance difference between cargo build and cargo build --release

[wiz21b]

Hello, I use your nice library for some drawing. Specifically:

		let gfx_elapsed = now.elapsed() - cpu_elapsed;

                    if pixels
			.render()
			.map_err(|e| error!("pixels.render() failed: {}", e))
			.is_err()
                    {
			*control_flow = ControlFlow::Exit;
			return;
                    }

		let pixels_elapsed = now.elapsed() - gfx_elapsed;

When building this code with cargo build, that section takes about 9ms. When building this code with cargo build --release, that section takes about 16.5ms. I've checked that the rest of the code does run faster. So the release build is 2x slower. Strangely, the time (16.5ms) is close to 1/60 of a second... My code is based on the winit minimal example, I don't fiddle with anything else.

Is it the expected behavior ?

I've checked the code of the crate but I'm new to rust so it's hard to find something by myself :-/

[wiz21b]

BTW, I'm running on Debian stable, with an NVIDIA gfx card, on regular KDE. I create the surface texture like this:

    let (window, p_width, p_height, mut _hidpi_factor) =
        create_window("AccurApple Emulator", &event_loop);
    let surface_texture = SurfaceTexture::new(p_width, p_height, &window);

[parasyte]

I can only guess that it has to do with the wgpu::PresentMode that you have configured (default is Fifo) in combination with your specific environment (driver, GPU, windowing system, etc).

Technical details: pixels.render() calls wgpu::SurfaceTexture::present(), which will use the given PresentMode to handle VSync (or not). This method blocks the current thread to synchronize with your display refresh rate when Fifo or Mailbox are used. If this is what you are experiencing, your best bet might be switching to Immediate and doing your own framerate limiting by sleeping the thread. (But watch out for framerate pacing issues.)

#174 has some info related to VSync, particularly how some other engines and games handle it.

In other words, this is not a performance issue. It is by design for simplicity. And handling display synchronization is hard.

[wiz21b]

Thx for your answer. In the meantime I guessed that it was on purpose because in debug mode and release mode, the total time needed to compute and render the frame is 16.6 (I didn't catch that when writing this issue). Thanks for the wgpu::PresentMode information, that will sure be helpful. My goal is to render frames at 50Hz on my 60Hz monitor which is doom to fail :-) (I write an emulator and it has to match the 50Hz to be correct,...)

[parasyte]

(I write an emulator and it has to match the 50Hz to be correct,...)

You will definitely have frame pacing issues if you do this the naive way; skip every 6th frame. A more advanced approach would involve blending frames to smooth out the stutter from skipping a frame. Similar to the telecine conversion method.

But yes, the total time for rendering is expected to be about 16.667ms on a 60 Hz display. The reason the release timing felt slower than debug is because you were timing the implicit sleep while the rest of the system was faster. So, it just had more time to sleep. :)