FFI calls are extremely slower than godot-cpp

[beicause]

I noticed processing a 1024x1024 image in godot-rust is very slow, which takes a few seconds.

godot-rust

    fn ready(&mut self) {
        let width = 1024;
        let height = 1024;
        let mut img =
            Image::create_empty(1024, 1024, false, godot::classes::image::Format::R8).unwrap();

        let t = std::time::Instant::now();
        for x in 0..width {
            for y in 0..height {
                img.set_pixel(
                    x,
                    y,
                    Color {
                        r: (x as f32) / 1024.0,
                        g: 0.0,
                        b: 0.0,
                        a: 0.0,
                    },
                );
            }
        }
        // img.save_png("res://t1.png");
        godot_print!("set pixel: {:?}", t.elapsed());

        let t = std::time::Instant::now();
        let mut buffer = PackedByteArray::new();
        buffer.resize((width * height).try_into().unwrap());
        for x in 0..width {
            for y in 0..height {
                buffer[(x + y * width) as usize] = ((x as f32) / 1024.0 * 255.0) as u8;
            }
        }
        img.set_data(
            width,
            height,
            false,
            godot::classes::image::Format::R8,
            &buffer,
        );
        // img.save_png("res://t2.png");
        godot_print!("set data: {:?}", t.elapsed());
    }

dev build, opt-level=0

set pixel: 1.521181788s
set data: 65.424402ms

dev build, opt-level=3

set pixel: 364.199245ms
set data: 26.16949ms

godot-cpp

	int width = 1024;
	int height = 1024;
	Ref<Image> img = Image::create_empty(1024, 1024, false, Image::FORMAT_R8);

	auto t = std::chrono::high_resolution_clock::now();
	for (int x = 0; x < width; x++) {
		for (int y = 0; y < height; y++) {
			img->set_pixel(x, y, Color((x) / 1024.0, 0.0, 0.0, 0.0));
		}
	}
	// img->save_png("res://t1.png");
	print_line("set pixel: ", std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::high_resolution_clock::now() - t).count());

	t = std::chrono::high_resolution_clock::now();
	PackedByteArray buffer;
	buffer.resize((width * height));
	for (int x = 0; x < width; x++) {
		for (int y = 0; y < height; y++) {
			buffer[(x + y * width)] = uint8_t(x / 1024.0 * 255.0);
		}
	}
	img->set_data(width, height, false, Image::FORMAT_R8, buffer);
	// img->save_png("res://t2.png");
	print_line("set data: ", std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::high_resolution_clock::now() - t).count());

dev build, optimize=none

set pixel: 24
set data: 7

dev build, optimize=speed

set pixel: 13
set data: 5

[Bromeon]

Hi, and thanks for the report! 🙂

Could you try to isolate a single FFI call that's slow, and show the direct comparison with godot-cpp? Then we can eliminate any other variables and focus on that.

One known difference is that godot-rust does a lot of additional runtime checks. You'll need to compile with --release (not just opt-level=3, but also turn off debug-assertions) to reduce them, but even then, some are left for safety. I already planned to make this more configurable.

Nonetheless, it's possible that there are other issues we haven't thought of, so reducing the problem would be welcome.

[beicause]

I think the set_pixel test has isolated a single ffi call, while the latter test may involve ffi calls related to PackedByteArray.

Release build (opt-level=3) is much faster, though still slower than godot-cpp:

set pixel: 47.871227ms
set data: 6.845521ms

[Yarwin]

I ran aforementioned godot-rust example six times, with and without ensure_object_alive check. Commenting out this check yields an extra performance (38,2ms avg vs 33,5ms avg for generating the image)... but doesn't explain so stark difference 🤔 (47ms vs 14ms).

gdext/godot-core/src/meta/signature.rs

Lines 303 to 305 in 0dde85e

	if let Some(instance_id) = maybe_instance_id {
	crate::classes::ensure_object_alive(instance_id, object_ptr, &call_ctx);
	}

There are some things to check there (we try to convert Ret despite it being null/None and it doesn't look like NoOP for example), preferably with right profiler 😅

(I wouldn't bother too much with set_data though, in my runs it fluctuated from 4.7ms to 5.6ms (what) with ~4,9ms average)

[beicause]

FYI, I disabled ensure_object_alive and check_rtti, then the performance became similar to godot-cpp's. I profiled it and found that both ClassName::to_cow_str and ensure_object_alive have a significant performance impact.

I‘d be surprised that we already checked instance id on every method call. And it’s so slow in debug mode that I had to use opt-level=1.

[Bromeon]

I‘d be surprised that we already checked instance id on every method call.

Not doing it would require marking every single method unsafe, since you can create UB by calling methods on dead objects.

But as mentioned before:

I already planned to make this more configurable.