What is the performance diff of Object vs Node vs Static class vs Global class

I am writing a class that does intensive numerical operations.

The issue is that there is no (apparent) need to derive this class from anything.

Performance is an issue, however.

So.

Is it better to derive from Object or Node?

Is it better to make all functions static or make it a “global”?

Keep in mind that “better” here means “faster performance”.

I will run some benchmarking but this is very precarious on Godot and perhaps someone has already experience with this.

Thank you all.

Depends on what you need as Node has scene tree hooks and Objects don’t, but i think both have a large memory foot print so cache thrashing may be a concern if you plan to store many instances in an array.

I’m not sure there is a meaningful difference. I assume both leverage the GDclassdatabase.

If you are using gdscript, use static typing, static type parameters and static type returns.

If you really need performance you will want to use C++ either with GDNative or GDExtension.

General practice is make your prototype, and then try to add performance where needed and where it can be gotten.

2 Likes

Thank you for the quick reply and insights into Godot. I remain a novice at it yet.

The class I am working on will not be instantiated so there are no objects to be concerned about. It is just a collection of (static) functions or, at most, a singleton class if that’s a better approach.

This brings about the issue of making it a class at all (derived from Object, or Node, or noting as nothing is not needed) or making it a Godot “Global” (which appears to turn the file into a static class of sorts internally).

Anyway, I have already made sure all parameters, variables, and returns are statically typed. I have also been mindful of known caveats such as avoiding the use of push_front or other similar functions that are memory-expensive and thus not performant.

The class is also already implemented but in c# (VS2022 has a far better debugging experience). I have used the outstanding BenchmarkDotNet library to compare its performance to other similar libraries and it smokes them all, including the one provided by Microsoft. So that part is covered.

The issue is to port it to GDScript (which should be easy) but that brought about interesting questions regarding inheritance and so on. Frankly, I need no Object or Node or anything. This is just a collection of static functions.

I guess I will try using Time.get_unix_time_from_system() to carry out some basic benchmarking and take it from there.

If any of this mess speaks to you (or anyone), I would appreciate a heads-up.

Thanks again.

You don’t need to derive from anything. Create a .gd file with your classes and/or static funcs. No need to load it, as long as you have a class name at top. E.g.:

main.gd

extends Control

func _ready()
    var sdata =Utils.load_from_file(path)
    var sarr = Utils.array_to_string(some_array)

    var res= Utils.Result.new()
    res.code=0
    res.value="some value"

utils.gd

class_name Utils

static func array_to_string(arr:Array) -> String:
	var s_str=""
	for i in arr:
		s_str+=String(i)
	return s_str

static func save_to_file(file_path: String, content: String):
	var file = FileAccess.open(file_path, FileAccess.WRITE)
	file.store_string(content)
	file.close()

static func load_from_file(file_path: String) -> String:
	print(file_path)
	var file = FileAccess.open(file_path, FileAccess.READ)
	var content = file.get_as_text()
	file.close()
	return content

static func open_file_manager(path):
	OS.shell_open(path)

# Use this class when you want to return either a value or an error code/description.
class Result:
	var code: int=0   # Error Code
	var description: String="" # Error Message
	var value: Variant # Value if no error
    

1 Like

So, in case someone else cares about this.

I have used Time.get_unix_time_from_system() to somehow “benchmark” the different options.

The one proposed by @wyattbiker is marginally better but, due to the low-quality benchmarking, possibly as good as making it a Godot “global”.