this post was submitted on 30 Sep 2023
24 points (96.2% liked)

Godot

5885 readers
33 users here now

Welcome to the programming.dev Godot community!

This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.

Make sure to follow the Godot CoC while chatting

We have a matrix room that can be used for chatting with other members of the community here

Links

Other Communities

Rules

We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent

Wormhole

[email protected]

Credits

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
24
Question about gdscript: Which is more efficient? (sopuli.xyz)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
21 comments fedilink hide all child comments
 

I’m just curious about which is the most efficient way of doing this kind of node enumiration:

for i in something():
    o=[var1,var2,var3,varN][i]
    o.new()
    o.do_something_based_on_number_of_loops()
    add_child(o)

or

for i in something():
    match i:
        0:
            o=var1
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)
        1:
            o=var2
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)
        2:
            o=var3
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)
        N-1:
            o=varN
            o.new()
            o.do_something_based_on_number_of_loops()
            add_child(o)

or

var items = [var1,var2,var3,varN]
for i in something():
    o=items[i]
    o.new()
    o.do_something_based_on_number_of_loops()
    add_child(o)

Or is there a more efficient way of doing it?

Edit: Sorry if that wasn't clear. Is it better to constantly get something from an "unstored list", store the list in a variable, or not use a list and use a match statement instead? Do they have any advantages/disadvantages that make them better in certain situations?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 11 points 1 year ago* (last edited 1 year ago) (4 children)

Rule #1 of programming: Write good code first, then measure performance.

Premature optimization is the root of all evil.

[–] [email protected] 7 points 1 year ago* (last edited 1 year ago) (1 children)

Rule number 2: stop dismissing performance questions just because of something some guy said decades ago. Performance matters, learning about performance matters, and answers like yours dont help anyone.

Did they ask if they should optimize, or did they ask which one generates more performant assembly? Which one of those questions did you answer?

Maybe they already measured and already knows this is a bottleneck. Maybe they are curious if match statements are a slow abstraction (e.g. in python, it's essentially a chain of if/else. In rust it's often compiled to an indexable table). Maybe the given example code is only partially representative of the actual code this is being applied to.

It's so irritating to look up performance-related questions when this answer is at the top (and middle, and bottom) of every thread. I swear half the reason every piece of modern software runs like shit is because nobody bothered to learn how to optimize and now everyone just parrots that phrase instead of saying "i dont know".

There's tons of little "premature" optimizations that you can do that arent evil. Choosing the right data structure (how random is the access? Are you using keys? Does it need to be sorted?). Estimating time complexity and load size (e.g. "i'm parsing [11 million | 2] files, i should probably [keep time complexity in mind | ignore time complexity completely]"). Structuring loops in a way that's easy for compilers to auto-vectorize - usually it's not any harder to read what the loop is doing, so why not do it right away?

Yes i'm bitter =(

[–] [email protected] 1 points 1 year ago (1 children)

stop dismissing performance questions

I did not dismiss it, I said measure the performance yourself.

Performance matters, learning about performance matters

Which is why I said you should measure performance. It's no use waffling about unmeasurable performance gains.

Did they ask if they should optimize, or did they ask which one generates more performant assembly?

To be pedantic, GDScript is an interpreted language, and does not generate bytecode or assembly. This means that the code performance is highly dependent on runtime conditions, and needs to be measured in the place where it's used.

Maybe they already measured and already knows this is a bottleneck.

If they already measured, then they would know which one is faster, because they measured it.

I swear half the reason every piece of modern software runs like shit is because nobody bothered to learn how to optimize

This is unrelated to what I said, which is "you should measure your performance to see what you need to optimize".

There’s tons of little “premature” optimizations that you can do that aren't evil.

And all of these optimizations are just as effective after you measure them to see if they're needed, and they're no longer premature.

Estimating time complexity and load size

Accurately estimating the performance impact of a design choice means the optimization is no longer premature. The rule-of-thumb is about using optimizations without taking appropriate time to their overall performance benefit. The particular question asked by the OP is very very unlikely to have any significant performance impact at all, unless it's in an extremely hot loop running millions of times per frame, at which point you should measure it to see which one is faster in your use case.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

I did not dismiss it, I said measure the performance yourself.

Then why does anyone ask anything? Just figure it out yourself. Oh you read a book or went to college? Why? Should have just reinvented computers yourself man. Taking advantage of collective knowledge is for suckers /s

This means that the code performance is highly dependent on runtime conditions, and needs to be measured in the place where it's used.

How is that helpful for OP? For example, if his question was about rust i'd say "options 1 or 2 should be identical for speed", but if it's python i'd say "match statements are just chained if/else chains, so a direct array index would be faster". For another example, in python attribute access is a function call. x.y in a loop is slower than assigning z = x.y outside of the loop and calling z in the loop.

You can absolutely generalize and have rules of thumb for performance.

If they already measured, then they would know which one is faster, because they measured it.

Measurements can have unintuitive results based on the dataset used (which, for benchmarks, usually end up being artificial datasets). OP's measurements may not have been consistent with their working understanding, thus they ask outside sources to confirm the truth. Idk why you cant just give them the benefit of the doubt and like... answer the question they actually asked? The explanations for "why" that accompany that answer can also be incredibly helpful.

And all of these optimizations are just as effective after you measure them to see if they're needed, and they're no longer premature.

That implies that these optimizations are harder than doing it the "mundane" way. They're not.

Here's a fun micro optimization for compiled languages: on modern CPUs

x = x * (arr[0] * arr[1]) in a loop has better performance characteristics than

x = (x * arr[0]) * arr[1]

even though they do the same thing (in short, it's because of the data dependencies for out-of-order execution - compilers wont make this optimization automatically for floats). How much harder is it to write the first one compared to the second one? How much harder to read is the first compared to the second?

So why would you not just make the first one your default? Now all your future uses of that pattern will perform better, for no extra effort except the amortized cognitive fee of changing your default option.

Look at OPs question. Could the answer fall under a rule of thumb that they can apply as their default option for a scenario? I'm pretty sure it can. So who cares about "premature" or not?

The particular question asked by the OP is very very unlikely to have any significant performance impact at all, unless it's in an extremely hot loop running millions of times per frame

So instead of answering their question, you assume it isnt impacting performance and they're just asking for no reason?

I literally had this exact question about python like 8 months ago. I had a file parser that needed to process different chunks based on a tag. Performance was critical, several thousand files, each ~3mb), the tag dispatch happened about 100,000-300,000 times per file. The original was implemented with if/else. I switched it to match because i thought it was faster, it wasnt. I looked at a lot of threads with answers like yours until stumbling upon dictionary dispatch (i.e. key = tag, value = first class function to call on the tag's data) and array dispatch.

That change alone was a 15% performance improvement.

You have no idea how their program works, what their hot loop is, if they're just asking out of curiosity, whatever. Just answer their fuckin question my dude. Platitudes are a waste of everyone's time.

[–] [email protected] 2 points 1 year ago* (last edited 1 year ago)

I'm with you. "Measure it yourself" is a bit of a non-answer. Sure, being able to measure things yourself is also a useful skill, but asking questions and having people with experience answer them is largely the point of places like this.

load more comments (2 replies)