https://gist.github.com/reduz/cb05fe96079e46785f08a79ec3b0ef21

Skip to content
 
[                    ]
All gists Back to GitHub Sign in Sign up
 
Sign in Sign up
You signed in with another tab or window. Reload to refresh your
session. You signed out in another tab or window. Reload to refresh
your session. You switched accounts on another tab or window. Reload
to refresh your session.
Dismiss alert
{{ message }}

Instantly share code, notes, and snippets.

@reduz

reduz/godot_binding_system_explained.md

Last active September 21, 2023 22:16

  * Star 48 You must be signed in to star a gist
  * Fork 3 You must be signed in to fork a gist

Star You must be signed in to star a gist
Code Revisions 10 Stars 48 Forks 3
Embed
What would you like to do?
">Embed Embed this gist in your website.
Share Copy sharable link for this gist.
Clone via HTTPS Clone with Git or checkout with SVN using the
repository's web address.
 
Learn more about clone URLs
[<script src="https:/]
 
Download ZIP
Raw
godot_binding_system_explained.md

During the past days, this great article by Sam Pruden has been
making the rounds around the gamedev community. While the article
provides an in-depth analysis, its a bit easy to miss the point and
exert the wrong conclusions from it. As such, and in many cases,
users unfamiliar with Godot internals have used it points such as
following:

  * Godot C# support is inefficient
  * Godot API and binding system is designed around GDScript
  * Godot is not production ready

In this brief article, I will shed a bit more light about how the
Godot binding system works and some detail on the Godot architecture.
This should hopefully help understand many of the technical decisions
behind it.

Built-in Types

Compared to other game engines, Godot is designed with a relatively
high level data model in mind. At the heart, it uses several
datatypes across the whole engine. These datatypes are:

  * Nil: To indicate an empty value.
  * Bool, Int64 and Float64: For scalar math.
  * String: For String and Unicode handling.
  * Vector2, Vector2i, Rect2, Rect2i, Transform2D: For 2D Vector
    math.
  * Vector3, Vector4, Quaternion, AABB, Plane, Projection, Basis,
    Transform3D: For 3D Vector math.
  * Color: For color space math.
  * StringName: For fast processing of Unique IDs (internally a
    unique pointer).
  * NodePath: For referencing paths between nodes in the Scene Tree.
  * RID: Resource ID for referencing a resource inside a server.
  * Object: An instance of a class.
  * Callable: A generic function pointer.
  * Signal: A signal (see Godot docs).
  * Dictionary: A generic dictionary (can contain any of these
    datatypes as either key or value).
  * Array: A generic array (can contain any of these datatypes).
  * PackedByteArray, PackedInt32Array, PackedInt64Array,
    PackedFloatArray, PackedDoubleArray: Scalar packed arrays.
  * PackedVector2Array, PackedVector3Array, PackedColorarray: Vector
    packed arrays.
  * PackedStringArray: Packed string array.

Does this mean that anything you do in Godot has to use these
datatypes? Absolutely not. These datatypes have several roles in
Godot:

  * Storage: Any of these datatypes can be saved to disk and loaded
    back very efficiently.
  * Transfer: These datatypes can be very efficiently marshalled and
    compressed for transfer over a network.
  * Introspection: Objects in Godot can only expose their properties
    as any of those datatypes.
  * Editing: When editing any object in Godot, it is done via any of
    these datatypes (of course, different editors can exist for the
    same datatype, depending on the context).
  * Languge API: Godot exposes its API to all languages it binds via
    those datatypes.

Of course, if you are absolutely unfamliar to Godot, the first
questions that come to mind are:

  * How do you expose more complex datatypes?
  * What about other datatypes such as int16?

In general, you can expose more complex datatypes via Object API, so
this is not much of an issue. Additionally, modern processors all
have at minimum 64 bit buses, so exposing anything other than 64 bit
scalar types makes no sense.

If you are unfamliar to Godot, I can totally understand the
disbelief. But in truth, it works fine and it makes everything far
simpler at the time of developing the engine. This data model is one
of the main reasons why Godot is such a tiny, efficient and yet
feature packed engine compared to the large mainstream mamooths. As
you get more familiar with the source code, you will start to see
why.

Language Binding System

Now that we have our data model, Godot imposes a strict requirement
that almost any function exposed to the engine API must be done via
those datatypes. Any function parameters, return types or properties
exposed must be via them too.

This makes the job of the binder much simpler. As such, Godot has
what we call an universal binder. How does this binder work, then?

Godot registers any C++ function to the binder like this:

Vector3 MyClass::my_function(const Vector3& p_argname) {
   //..//
}

// Then, on a special function, Godot does:

// Describe the method as having a name and the name of the argument, the pass the method pointer
ClassDB::bind_method(D_METHOD("my_function","my_argname"), &MyClass::my_function);

Internally, my_function and my_argument are converted to a StringName
(described above), so from now onwards they are treated just as a
unique pointer by the binding API. In fact, when compiling on
release, the argument name is ignored by the template and no code is
generated, since it serves no purpose.

So, what does ClassDB::bind_method do? If you want to dive into the
depths of insanity and try to understand the incredibly complex and
optimized C++17 variadic templates black magic, feel free to go ahead
.

But In short, it creates a static function like this, which Godot
calls "ptrcall" form.:

// Not really done like this, but simplifying as much as possible so you get an idea:

static void my_function_ptrcall(void *instance, void **arguments, void *ret_value) {
    MyClass *c = (MyClass*)instance;
    Vector3 *ret = (Vector3*)ret_value;
    *ret = c->my_method( *(Vector3*)arguments[0] );
}

This wrapper is basically as efficient as it can be. In fact, for
critical functions, inline is forced into the class method, resulting
in a C function pointer to the actual function code.

Then Language API works by allowing the request of any engine
function in "ptrcall" format. To call this format, the language must:

  * Allocate a bit of stack (basically just adjusting the stack
    pointer of the CPU)
  * set a pointer to the arguments (which already exist in native
    form in this language 1:1, be it GodotCPP, C#, Rust, etc).
  * call.

And that's it. This is an incredibly efficient generic glue API that
you can use to expose any language to Godot efficiently.

So, as you can imagine, the C# API in Godot basically uses a C
function pointer via unsafe API to call after assigning pointers to
native C# types. It is very, very efficient.

Godot is not the new Unity - The anatomy of a Godot API call

I want to insist that the article written by Sam Pruden is fantastic,
but if you are not familiar with how Godot is intended to work under
the hood it can be very misleading. I will proceed to explain a bit
more in detail what is easy to misunderstand.

Only a pathological use case is shown, the rest of the API is fine.

The use case shown in the article, the ray_cast function, is a
pathological one in the Godot API. Cases like this are most likely
less 0.01% of the API exposed by Godot. It looks like the author
found this by coincidence when trying to profile raycasting, but it
is not representative of the rest of the bindings.

The problem is that, at the C++ level, this function takes a struct
pointer for performance. But at the language binding API this is
difficult to expose properly. This is very old code (dating to the
opensourcing of Godot) and a Dictionary was hacked-in to use
temporarily until something better is found. Of course, other stuff
was more prioritary and very few games need thousands of raycasts, so
pretty much nobody complained. Still, there is a recently open
proposal to discuss more efficient binding of these types of
functions.

Additionally, to add to how unfortunate this choice of function is,
the Godot language binding system does support struct pointers like
this. GodotCPP and Rust bindings can use pointers to structs without
any issue. The problem is that C# support in Godot predates the
extension system and it was not converted to it yet. Eventually, C#
will be moved to the universal extension system and this will allow
the unifying of the default and .net editors, it is just not the case
yet, but its top in the list of priorities.

The workaround is even more pathological

Although this time, due to a limitation of C#. If you bind C++ to C#,
you need to create a C# version of a C++ instance as an adapter. This
is not an unique problem to Godot, any other engine or application
doing this will require the same.

Why is it troublesome? because C# has a garbage collector and C++
does not. This forces the C++ instance to keep a link to the C#
instance to avoid it from being collected.

Due to this, the C# binder must do extra work when calling Godot
functions that take class instances. You can see this code in Sam's
article:

public static GodotObject UnmanagedGetManaged(IntPtr unmanaged)
{
    if (unmanaged == IntPtr.Zero) return null;

    IntPtr intPtr = NativeFuncs.godotsharp_internal_unmanaged_get_script_instance_managed(unmanaged, out var r_has_cs_script_instance);
    if (intPtr != IntPtr.Zero) return (GodotObject)GCHandle.FromIntPtr(intPtr).Target;
    if (r_has_cs_script_instance.ToBool()) return null;

    intPtr = NativeFuncs.godotsharp_internal_unmanaged_get_instance_binding_managed(unmanaged);
    object obj = ((intPtr != IntPtr.Zero) ? GCHandle.FromIntPtr(intPtr).Target : null);
    if (obj != null) return (GodotObject)obj;

    intPtr = NativeFuncs.godotsharp_internal_unmanaged_instance_binding_create_managed(unmanaged, intPtr);
    if (!(intPtr != IntPtr.Zero)) return null;

    return (GodotObject)GCHandle.FromIntPtr(intPtr).Target;
}

While very efficient, it's still not ideal for hot paths so the Godot
API exposed is considerate and does not expose anything critical this
way. The workaround used, however, is quite complex and hits this
path due to not using the actual function intended for it.

The question of cherry picking

I firmly believe the author did not cherry pick this API on purpose.
In fact, he himself writes that he checked other places of API usages
and did not find anything with this level of pathology either.

To clarify further, he mentions:

Let's also remember that Dictionary is only part of the problem. If we look a little wider for things returning
Godot.Collections.Array<T> (remember: heap allocated, contents as Variant) we find lots from physics,
mesh & geometry manipulation, navigation, tilemaps, rendering, and more.

From my side and contributors side, none of those usages are hot
paths or pathological. Remember that, as I mentioned above, Godot
uses the Godot types mainly for serialization and API communication.
While it is true that they do heap allocation, this only happens once
when the data is created.

I think what may have confused Sam and a few others in this area
(which is normal if you are not familiar with the Godot codebase) is
that Godot containers don't work like STL containers. Because they
are used mainly to pass data around, they are allocated once and then
kept via reference counting.

This means, the function that reads your mesh data from disk is the
only one doing the allocation, then this pointer gets passed through
many layers via reference counting until arrives Vulkan and is
uploaded to the GPU. Zero copies happen along the way.

Likewise, when these containers are exposed to C# via the Godot
collections, they are also reference counted internally. If you
create one of those arrays to pass the the Godot API, the allocation
only happens once. Then no further copies happen and the data arrives
intact to the consumer.

Of course, intenally, Godot uses far more optimized containers that
are not directly exposed to the binder API.

Misleading conclusion

The article concludes like this:

Godot has made a philosophical decision to be slow. The only practical way to interact with the engine is via this binding layer, and its core design prevents it from ever being fast. No amount of optimising the implementation of Dictionary or speeding up the physics engine is going to get around the fact we're passing large heap allocated values around when we should be dealing with tiny structs. While C# and GDScript APIs remain synchronised, this will always hold the engine back.

As you have read in the above points, the binding layer is absolutely
not slow. What can be slow is an extremely limited amount of use
cases that can be pathological. For those cases, a dedicated solution
is found. This is a general philosophy behind Godot development that
helps keep the codebase small, tidy, maintainable and easy to
understand.

In other words, this principle:

image

The current binder serves its purpose and works well and efficiently
for over 99.99% of use cases. For the exceptional ones, as mentioned
before, the extension API supports structs already (which you can see
here in this excerpt of the extension api dump):

                {
                        "name": "PhysicsServer2DExtensionRayResult",
                        "format": "Vector2 position;Vector2 normal;RID rid;ObjectID collider_id;Object *collider;int shape"
                },
                {
                        "name": "PhysicsServer2DExtensionShapeRestInfo",
                        "format": "Vector2 point;Vector2 normal;RID rid;ObjectID collider_id;int shape;Vector2 linear_velocity"
                },
                {
                        "name": "PhysicsServer2DExtensionShapeResult",
                        "format": "RID rid;ObjectID collider_id;Object *collider;int shape"
                },
                {
                        "name": "PhysicsServer3DExtensionMotionCollision",
                        "format": "Vector3 position;Vector3 normal;Vector3 collider_velocity;Vector3 collider_angular_velocity;real_t depth;int local_shape;ObjectID collider_id;RID collider;int collider_shape"
                },
                {
                        "name": "PhysicsServer3DExtensionMotionResult",
                        "format": "Vector3 travel;Vector3 remainder;real_t collision_depth;real_t collision_safe_fraction;real_t collision_unsafe_fraction;PhysicsServer3DExtensionMotionCollision collisions[32];int collision_count"
                },

So, ultimately, I believe that the conclusion that "Godot is slow by
design" is a bit rushed. What is currently missing is the move of the
C# language to the GDExtension system in order to be able to take
advantage of these. This is currently a work in progress.

To sum up

I hope that this short article is used to dispell a few
misconceptions that unintentionally arised from Sam's excellent
article:

  * Godot C# API is inefficient: This is absolutely not the case, but
    very few pathological cases remain to be solved and were already
    being in discussion before last week. In practice, very very few
    games may run into them and, by next year, hopefully none.
  * Godot API is designed around GDScript: This is also not true. In
    fact, until Godot 4.1, typed GDScript did calls via "ptrcall"
    syntax, and the argument encoding was a bottleneck. As a result,
    we created a special path for GDScript to call more efficiently.

Thanks for reading and remember that Godot is not commercial software
developed behind closed doors. All of us who make it are available
online in the same communities as you. If you have any doubt, feel
free to ask us directly.

Bonus: As a side note, and contrary to popular belief, the Godot data
model was not created for GDScript. Originaly, the engine used other
languages such as Lua or Squirrel, with several published games while
an in-house engine. GDScript was developed afterwards.

Load earlier comments...
@pkdawson
Copy link

pkdawson commented Sep 21, 2023

There are places in the C# API where a method like
RenderingServer::canvas_item_add_triangle_array accepts normal C#
arrays, then the glue code makes copies of those into native
Packed*Arrays. That's pretty expensive when the arrays can be large.

Where possible, I'd love to have the API accept read-only array
parameters as generic spans (see std::span or C#'s Span), to avoid
requiring a copy.

But I agree that most of the C# API is fine, and large arrays are
another "pathological case".

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023

@pkdawson Spans are not going to happen, as Godot already supports
these things via reference counted buffers. Maybe what should be done
is change the C# API to only accept Godot collections instead.

Sorry, something went wrong.

@Exerionius
Copy link

Exerionius commented Sep 21, 2023

Thanks for the insights!

Did you mean my_function instead of my_fufunction here?

// Describe the method as having a name and the name of the argument, the pass the method pointer
ClassDB::bind_method(D_METHOD("my_fufunction","my_argname"), &MyClass::my_function);

Also here:

    ...but if you are not familiar with how Godot it can be very
    misleading...

With how Godot what?

Sorry, something went wrong.

@jsjtxietian
Copy link

jsjtxietian commented Sep 21, 2023

Thanks a lot for the article, that explains a lot!

I wonder if Godot has a collection of Engine design choices or
architecture explainations like this article somewhere? For a new
contributor like me, I'd love to read more. I checked the official
doc but it's more general than this article. While one can read the
code to learn the actual design, it's still better to have a guide
like this.

Sorry, something went wrong.

@wareya
Copy link

wareya commented Sep 21, 2023

    There are places in the C# API where a method like
    RenderingServer::canvas_item_add_triangle_array accepts normal C#
    arrays, then the glue code makes copies of those into native
    Packed*Arrays. That's pretty expensive when the arrays can be
    large.

I'm getting bitten by the packed array copies in my minecraft clone.
I'm thinking it might make sense to expose the packed array types to
C# instead of converting them back and forth with native arrays,
especially now that packed arrays are no longer value types (like
they were in godot 3).

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023

I do agree this is not the best in retrospect. The C# team had a lot
of freedom because they truly tried to make the bindings as nice to
use as possible to Untiy/XNA users, but I guess this was a mistake.

Sorry, something went wrong.

@wareya
Copy link

wareya commented Sep 21, 2023

It makes perfect sense for godot 3 at least, since they act like
value types there.

Sorry, something went wrong.

@SamPruden
Copy link

SamPruden commented Sep 21, 2023

Thanks for doing this response @reduz and sorry that you had to! I'll
reply in a little more detail shortly, but as it's pertinent to these
comments I thought I should quickly drop here this list of all
methods (I think it's complete and correct...) which return some type
of array.

https://gist.github.com/SamPruden/1bc57921f81c210c58e4880fc076b1ab

I agree many look like they're not hot path methods, but there are a
few areas (like navigation, meshes, particles, polygons, and of
course physics) which look potentially hot.

This was generated by running a quick python script over the JSON
ClassDB output and filtering for return values containing "array"
(ignoring case).

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023 *
edited

@SamPruden I think returning or passing arrays is fine. Normally
these are not hot paths.
I think the problem is as @wareya mentions, that the current C#
bindings are using C# datatypes where they should be Godot
collections.
IMO this needs to be fixed in Godot 4.x, probably even implementing
something akin to TypedArray there.

Sorry, something went wrong.

@winston-yallow
Copy link

winston-yallow commented Sep 21, 2023 *
edited

Thank you @SamPruden too for helping and pointing out constructive
ways to improve it! It's been really nice seeing all the
conversations going on in the dev chat, just like open source should
work 

(As for Godot, this has been really helpful for me to understand the
engine more in-depth. Maybe I'll finally get to contribute more)

Sorry, something went wrong.

@SamPruden
Copy link

SamPruden commented Sep 21, 2023

@reduz the problem with Godot arrays in C# is that they're still
classes. That means that every return creates garbage, which means
garbage collection will run sometime, which can cause dropped frames.
It may be small garbage because it's only a pointer, but it's garbage
nonetheless. From Unity, my standard rule is zero garbage in a frame.

Sorry, something went wrong.

@adrian17
Copy link

adrian17 commented Sep 21, 2023

    Maybe what should be done is change the C# API to only accept
    Godot collections instead.

    I think the problem is as @wareya mentions, that the current C#
    bindings are using C# datatypes where they should be Godot
    collections.

Ignoring whether refcounted buffers are a good Span equivalent, C#
API accepting Godot collections only pushes the problem down the
chain. C# programmers will want to keep using standard C# code and
libraries, which means they would still need to convert between an
array, List, Span or other .NET collection and a Godot collection at
some point, right?

Sorry, something went wrong.

@SamPruden
Copy link

SamPruden commented Sep 21, 2023

No worries @winston-yallow!

I actually feel bad about the amount of negative attention I brought
Godot's way! I never believed even 100 people would read my 5,800
word boring technical article on a brand new blog, but somehow it's
now sitting at 25,000 views... I should have been more careful and
more rigorous - I was intending to document my discovery process, not
to establish a community opinion as if I were some authority figure.

There are some parts of the article that are a bit sloppy, although I
do also think that the situation is maybe a little worse than some
people realise because of e.g. Godot collections still being an
issue.

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023

@SamPruden

    From Unity, my standard rule is zero garbage in a frame.

I understand this, but you are misunderstanding their use case:

 1. No hot path relies on returning arrays currently,
 2. Some hot paths may rely on sending arrays, (like @wareya
    mentions) but you can reuse them without an issue or even pool
    them if you want, that's up to you.

Sorry, something went wrong.

@wareya
Copy link

wareya commented Sep 21, 2023

    Ignoring whether refcounted buffers are a good Span equivalent, C
    # API accepting Godot collections only pushes the problem down
    the chain. C# programmers will want to keep using standard C#
    code and libraries, which means they would still need to convert
    between an array, List, Span or other .NET collection and a Godot
    collection at some point, right?

There are only really three options here: one, design the native code
around C# types, which is bad; two, write your C# code around C#
containers and convert to native containers later; or three, write C#
code that uses thin no-copy wrappers over the native containers. The
hidden fourth option is writing unsafe C# code that interacts
directly with native containers, but that's a really bad idea.

Sorry, something went wrong.

@SamPruden
Copy link

SamPruden commented Sep 21, 2023 *
edited

Defining "hot path" as anything you might do in a frame that's not a
rare exception, there probably are, and definitely will be, lots of
methods that want to return multiple values. Even if they're not
official APIs, there still needs to be a blessed way for assets to do
this.

Sticking with the physics example, in my current (or ex, I guess?)
Unity project I do lots of shape casts and overlap tests, each which
return multiple values. For some of those, I also actually get the
vertices of the hit polygons, another array return.

As far as I've seen, Godot currently has no good mechanism for that.
Godot collections are classes, so allocating and returning them in C#
doesn't work out.

The standard tricks are that your API either accepts a pre-allocated
buffer to write into (either cached/pooled, or created spontaneously
in unmanaged memory) or returns unmanaged memory which the user has
to take responsibility for disposing manually. (This can be done as a
struct, because no deconstructor is needed, but should be a last
resort because of C# expects better memory safety than this. ref
struct helps though.)

Sorry, something went wrong.

@SamPruden
Copy link

SamPruden commented Sep 21, 2023

One other idea I've been playing around with is frame lifetime bump
allocators.

If you're calling something in the update loop, you probably only
want the data for the duration of that frame. If you direct it to
allocate into a frame duration buffer, you get automatic management
of unmanaged memory for free - just one pointer gets reset at the end
of every frame.

As long as the allocation from that buffer is only ever given over in
a ref struct (e.g. Span<T>) then I think it's fully safe - assuming
no stack ever outlasts a frame...

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023 *
edited

@adrian17

    Ignoring whether refcounted buffers are a good Span equivalent, C
    # API accepting Godot collections only pushes the problem down
    the chain. C# programmers will want to keep using standard C#
    code and libraries, which means they would still need to convert
    between an array, List, Span or other .NET collection and a Godot
    collection at some point, right?

The "problem" you mention (if you want to see it as a problem) is
unsolvable at any point in the chain because Godot uses a refcounted
buffers data model with a specific purpose, not spans, which have a
different purpose. Replacing one by the other is not logical.

This is why, if you use Godot collections in C# side, at least you
can avoid the extra copies if you want to keep within the Godot
context, and have efficient code to convert it to/from to C# native
datatypes if you really want to use something else. Just pool them or
do whathever.

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023

@SamPruden

    Defining "hot path" as anything you might do in a frame that's
    not a rare exception, there probably are, and definitely will be,
    lots of methods that want to return multiple values. Even if
    they're not official APIs, there still needs to be a blessed way
    for assets to do this.

This is what the struct proposal is about for the most part. In hot
paths it can be passed as argument. At the native level, the struct
pointers are the same but more efficient when exposing API.

    As far as I've seen, Godot currently has no good mechanism for
    that. Godot collections are classes, so allocating and returning
    them in C# doesn't work out.

Again, for non-critical stuff, its fine. I understand the obsession
with the GC in C# but a couple hundred pointers freed per frame is
fine. the problem is more when you have dozens of thousands. The
priority is to only have the critical paths covered with a
non-allocation policy.

    The standard tricks are that your API either excepts a
    pre-allocated buffer to write into (either cached/pooled, or
    created spontaneously in unmanaged memory) or returns unmanaged
    memory which the user has to take responsibility for disposing
    manually.

I agree with this, and Godot does support this, but the APIs are
simply not exposed like this when not critical.

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023 *
edited

@SamPruden

    One other idea I've been playing around with is frame lifetime
    bump allocators.

On anecdoatal note, this is very common in some game engines, they
call it stack allocators. But this assumes too much and makes the
engine more complex than it needs to be. It makes sense for AAA.
Internally, for this Godod uses something worst case allocators,
which is similar but more flexible. This is not exposed to binder API
and makes no sense to expose it though.

    If you're calling something in the update loop, you probably only
    want the data for the duration of that frame. If you direct it to
    allocate into a frame duration buffer, you get automatic
    management of unmanaged memory for free - just one pointer gets
    reset at the end of every frame.

The engine just does not work like this, and neither GDScript nor C++
have problems with GC. And even so, I don't think the problems
expressed regarding the GC are real in this context. I used languages
with far shitter GC in the past (lua as example) and to hit GC stall
you really have to do a shitton of allocations per frame, not just a
bunch. And this was more than a decade ago.

So I insist, I entirely agree with your take that critical functions
like raycast need a fast path with no allocation, and a method that
users can use in add-ons if they want to do this too, but thinking of
changing all allocation policies of all usages is a bit much. You are
trying to kill a mosquito with a bazooka.

Sorry, something went wrong.

@wareya
Copy link

wareya commented Sep 21, 2023

If the C# GC fails to gradually collect garbage as it should, and the
dozens or hundreds of objects you're allocating build up to many
thousand over the course of several frames, you can force the GC to
run at the end of every frame. (Ideally you would run it after
dispatching rendering commands and before running the framerate
limiter / before waiting for vsync, but I'm not sure there's anything
exposed to run code at exactly that time.)

But also, godot uses a much newer version of C# than unity does, with
a much better GC, so this is less likely to be necessary than it is
in unity.

Sorry, something went wrong.

@SamPruden
Copy link

SamPruden commented Sep 21, 2023

@reduz You're probably right about small GC not being that big of a
deal. I suppose we can get a fairly objective answer to this with
benchmarks and profiling. I'll see if I can throw something together
and report back.

Anecdotally, I know that even small numbers of small allocations used
to cause bad problems in Mono, although that was a few years back
that I checked. It's likely this is less of an issue with the runtime
used here, although it sounds like (from what I picked up in the
DotNet meeting earlier) the Mono runtime may still be used on some
platforms - so it's probably hard to do a universal benchmark across
all use cases.

RE bump allocator, I was actually thinking about doing that entirely
in C# land, then using it for the "I give you buffer, you give me
data" approach. It's a more ergonomic version of that pattern,
because you don't need to awkwardly create and cache a List<T> in a
field somewhere for use as an implementation detail of some method.

My opinion would still be: If we have a good pattern for doing zero
allocations, that should probably be done everywhere whether or not
it's significant, because why not? This guards against weird problems
where e.g the GC is particularly poor on some future platform/
runtime. I'm also a little uncomfortable with the engine making
judgements about which methods are hot path and which aren't - users
will find unanticipated hot path usecases for things.

I'm afraid that throughout this process over the last few days, the
relevance of the struct proposal has alluded me. There's been quite a
lot of confusion in various discussions due to the overloaded
terminology - the reference counted struct in that proposal seems
very different from the value type "native struct" that would most
obviously help with things in C#.

Sorry, something went wrong.

@SamPruden
Copy link

SamPruden commented Sep 21, 2023

Although #81004 looks like a fun struct PR that could use some love
:)

Sorry, something went wrong.

@lrahmann
Copy link

lrahmann commented Sep 21, 2023

Not sure how relevant that is these days, and it only matters for C#
anyways. But on some platforms without a generational multi threaded
or incremental GC (e.g. Unity until a few years ago on consoles etc.)
running the GC always meant scanning the whole heap resulting in a
noticeable lag. The only way to get around this was not triggering
the GC by having a zero new object count.
Unity went even further with .DOTS which also reduces the size of the
managed heap.

Sorry, something went wrong.

@ChrisAbra
Copy link

ChrisAbra commented Sep 21, 2023

Perhaps naively jumping in on this one, but dotnet allows alternative
garbage collectors .
If the core-side is already being refcounted anyway, would it make
sense not to extend/replace the C# GC? At least for garbage that's
created in these interface layers. Or otherwise modifying the default
behaviour of the dotnet GC given its running under a more predictable
/known circumstnaces?

It makes sense not to do allocations in hotpaths (and it seems
largely the engine does not) but if we know what allocations we're
doing and likely to do, we could account for it?

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023

@SamPruden

    My opinion would still be: If we have a good pattern for doing
    zero allocations, that should probably be done everywhere whether
    or not it's significant, because why not?

To me this is solutions in search of a problem. The advantage of the
current API is that its exposed in a very simple and predictable way.
It's very difficult to write software based on speculation on what
will be best and what will be fast, or even based on benchmarks that
don't have any real-world usage scenario behind them.

It's easier to write software to react to real-world bottlenecks. As
an example, the current ray_cast function you found was indeed slow,
but thousands of Godot games have been published to Steam with Godot
and nobody ever complained. This means no one used it as much as you
intended it to. Now that you stumbled into this problem, there is
more motivation to fix this, otherwise all this is premature
optimization.

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023

@lrahmann I trust that current C# is far more capable than older
versions of Unity in terms of GC. I think we first have to see how
well it works, then see whether optimizations make sense.

Sorry, something went wrong.

@jams3223
Copy link

jams3223 commented Sep 21, 2023 *
edited

    @lrahmann I trust that current C# is far more capable than older
    versions of Unity in terms of GC. I think we first have to see
    how well it works, then see whether optimizations make sense.

Actually, the raycast problems cause more issues in games published
on Steam than you think, especially with games where there's a lot of
enemies moving around, which could even cause some performance issues
on multiplayer games made with the engine. I've encountered that
issue with 2D games where I had to run them at 30 FPS just because
there were many enemies on the screen, so they became CPU-bound.

Sorry, something went wrong.

@reduz
Copy link
Author

reduz commented Sep 21, 2023 *
edited

@jams3223 That sucks to know, but either case it is still something
that was on track to be fixed anyway. Its just that it did not seem
so urgent based on user feedback to justify prioritizing it.

Sorry, something went wrong.

@jams3223
Copy link

jams3223 commented Sep 21, 2023

    @jams3223 That sucks to know, but either case it is still
    something that was on track to be fixed anyway. Its just that it
    did not seem so urgent based on user feedback to justify
    prioritizing it.

As long as we put our head together we can make the engine better,
also we need more reviewers for pull request, they're taking a long
time to be reviewed since purge request has increased this year.

Sorry, something went wrong.

Sign up for free to join this conversation on GitHub. Already have an
account? Sign in to comment

Footer

 (c) 2023 GitHub, Inc.

Footer navigation

  * Terms
  * Privacy
  * Security
  * Status
  * Docs
  * Contact GitHub
  * Pricing
  * API
  * Training
  * Blog
  * About

You can't perform that action at this time.