Godot代码优化 - 从另一个节点调用值
有一个问题，即如何从一个函数中的另一个节点中获得值更好。
我有这个代码，多次从另一个节点获得相同的值：
func locrestrict(transformX, transformY):
self.transform.origin.x = clamp(transformX, -cam_node.cam_bounds.x - 1, cam_node.cam_bounds.x + 1)
self.transform.origin.y = clamp(transformY, cam_node.cam_bounds.y - 1, -cam_node.cam_bounds.y * 2)
if cam_node.translation != cam_node.cam_init:
self.transform.origin.x = clamp(transformX,
-cam_node.cam_bounds.x - 1 + (cam_node.translation.x - cam_node.cam_init.x),
cam_node.cam_bounds.x + 1 + (cam_node.translation.x - cam_node.cam_init.x))
self.transform.origin.y = clamp(transformY,
cam_node.cam_bounds.y - 1 + (cam_node.translation.y - cam_node.cam_init.y),
-cam_node.cam_bounds.y * 2 + (cam_node.translation.y - cam_node.cam_init.y))
Godot将自动从内存中使用相同的记录来从所有这些操作中使用相同的记录，或者最好在函数开始时进行临时值，以防止多个节点调用？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在Godot 3.X中没有进行任何此类优化。但是，预计绩效很少。原因是在Godot 3.x GDScript中是一种解释的语言，而Godot仍然必须弄清楚您正在访问的内容（是否本地变量）。
我建议您尝试 Profiler 找出哪些功能实际上在运行时很昂贵，然后开始。而当我们这样做的时候，不要相信我的话。如果此功能性能很重要，请尝试您的优化，并查看它是否对profiler有所不同。
在Godot 4.0中，GDScript被编译为虚拟机。我不知道编译器有多聪明，或者将在Godot 4.0的稳定版本中。
我还想说，优化并不总是要更快地做事。有时，这是少做的或做的频率较低。
例如，此功能可能不是一个性能问题，但是如果必须每帧运行数万次，则可能是。
看起来 - 我不确定我充分理解代码 - 您正在实现
drag_margin _*和限制_*camera2d的属性。如果您可以让camera2d为您执行此操作，而不是在GDScript中编写它，则可以更好地性能。 这是通过少做的。无论如何，手头的功能取决于特定的变换。如果您有理由相信它可能不会更改每个帧，那么您可能只会在此代码时受益（例如，使用
notification_transform_changed）。另请参见在更改位置时如何调用函数？。 这是一种优化的优化。顺便说一句优化。在Godot 3.x中键入您的变量几乎没有影响，但是在Godot 4.0中确实具有影响。我建议把它作为好习惯。在这种情况下，看来参数应为
float，并且该方法为void（不返回）：否则，您将它们定义为变体。戈多必须弄清楚每次都存储在变体中的类型。
在Godot 3.X中对性能产生更明显影响的事情正在利用某些类型的优势。特别是考虑使用
vector2。如果您可以利用向量的优势在较少的说明中对多个值进行操作，则意味着戈多需要将较少的指示解释以归档相同的结果，从而更好地绩效。 这是通过少做的。gdquest有一些有关GDScript的文章，您可能会发现有用（他们确实花费了一些时间来确定实际有效的方法）：
注意：即使术语“类型提示”卡住了，它们是实际的类型声明。
您还可以考虑使用C＃甚至C ++作为对代码关键部分的优化途径。 GDScript是一种很棒的胶水语言，也是出色的原型语言。然而，有价值将昂贵的计算移植到另一种语言中。 这将是通过更快地做事的优化。尽管我不认为问题中的代码是一个昂贵的计算。
In Godot 3.x does not do any such optimizations. However, expect very little performance improvement. The reason being that in Godot 3.x GDScript is an interpreted language, and Godot still has to figure out what you are accessing (local variable or not).
I suggest you try the profiler to find out what functions are actually expensive in runtime and begin there. And while we are at it, don't take my word for it. If this function performance is important, try the optimization you have in mind, and see if it made any difference in the profiler.
In Godot 4.0 GDScript is compiled to a virtual machine. I don't know how smart the compiler is, or will be in the stable release of Godot 4.0.
I also want to say that optimization isn't always about doing things faster. Sometimes it is about doing less, or doing less frequently.
For instance, this function as is, probably isn't a performance issue, but if it has to run tens of thousands of times per frame, it might be.
It appears - I'm not sure I fully understand the code - you are implementing the functionality of
drag_margin_*andlimit_*properties of aCamera2D. If you can have theCamera2Ddo this for you, instead of writing it in GDScript, you will have better performance. This is an optimization by doing less.Anyway, it appears the function at hand depends on a particular transform changing. If you have reason to believe it might not change every frame, then you might benefit from only calling this code when it does (e.g. using
NOTIFICATION_TRANSFORM_CHANGED). See also How to invoke a function when changing position?. This is an optimization by doing less frequently.By the way, speaking of optimizations. Typing your variables in Godot 3.x has virtually no impact, but does have it in Godot 4.0. I suggest to take it as good practice. In this case it appears the parameters should be
float, and the method isvoid(does not return):Otherwise you are defining them to be variant. And Godot has to figure out the type of what is stored in the variant every time.
Something that will have a more noticiable impact in performance in Godot 3.x is taking advantage of some types. In particular, consider using
Vector2. If you can take advantages of vectors to operate on multiple values in less instructions, it means Godot needs to interpret less instruction to archive the same result, and thus better performance. This is an optimization by doing less.GDQuest has a few articles about GDScript that you may find useful (they did expend some time figuring what actually works):
Note: Even though the term "type hints" stuck, they are actual type declarations.
You may also consider using C# or even C++ as avenues of optimization for the critical parts of your code. GDScript is a great glue language, and also great prototyping language. Yet there is value is porting expensive computations to another language. This would be an optimization by doing things faster. Although I won't consider the code in the question to be an expensive computation.