understanding how abstraction doesnt slow down performance...

I have a very long code... It is sorting 32 gameobjects into two of six lists. These lists are calculating 6 different variables (used by the AI manager) as well as indicating an index for each variable... Currently for each object I am using two 'Transforms' and a 'RectTransform'.

My point is... Looking at how awkward the script is to read, I have looked into using my 'slowly learning' skills of abstraction, encapsulation and classes etc. To split the script up in to 6 different scripts, one for each list, and further breaking down the methods inside.... But, to do this I am going to need to call those twenty-two lots of 'two Transforms and Rectransform', six times...(3*32*6 = 576 times) Where as with my long clumsy code, I only call (32* 3 = 96 times)...

At what point does this help me? Can you see my point? Presuming I am caching the hidden <GetComponent>

 

Perhaps the most important kind of performance is programmer performance. That is, how long does it take for you to read, understand, and fix a problem in a bit of code. "Clumsy" code that has a slight performance boost that has a bug that takes forever to figure out is not better than slightly slower code where you can find and fix the problem you can find quickly.

Preoptimization is a the death of success. Does this list sorting need to be done every frame, or just once?

If your abstraction requires three times as many calculations... perhaps you could have abstracted it better?

 

Haha thanks! No, I am using a coroutine to do it every 0.2 seconds (may be quicker)

What do people mean by "Preoptimization is a the death of success"? I have read that many times and don't get the point? How can it be a bad thing?

 

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." - Donald Knuth

As I generally put it, optimize when and where your profiler shows that you need to.

 

Thanks I get it, like the perfectionist nature of it all...

When would the profile tell me, I am looking at the time it takes to render each frame right?

 

Yes, and it breaks down which components are taking the longest time each frame. You can see where your spikes are, how many milliseconds each script is consuming each frame, etc.

As a general rule, write your code in a clear, easy to understand manner. Solve your problems in the manner that makes sense to you. When you start seeing problems, cleaner code will help you find and resolve the problem faster. Trying to be super optimal up front generally leads to much harder to understand code.

 

Some random thoughts on the topic.

If your abstraction makes your code harder to work with then you are doing it wrong. In general abstraction should not lead to you doing the same calculation in multiple places either.

Another misconception to clear up, proper coding principles will not make your code perform faster. It typically makes it perform worse, but rapidly improves development and bug fixing time. In most cases saving years off of development time is worth the performance cost.

There is the concept of hot code. Hot code is code that must run rapidly in order to make your product performant. This is the loop that gets called 5000 times a frame. In hot code you do all sorts of tricks to improve performance at the cost of readability, sometimes even dropping down to the underlying assembly level code. You typically cannot determine what falls into this hot code area until you have completed your game. No point shaving milliseconds off a routine that runs once an hour.

In general you get the best performance improvements by choosing the best algorithm to work with. This is better done when the code is totally readable, before any optimisation is done. After all, no point spending time on a class that runs perfectly if the entire class does not belong in your product.

So wait until the product is done before doing too much optimisation. And start from the top and work your way down.

 

This isn't a game design topic...

 

True, probably belongs in scripting for better answers and discussion.

 

True, but I do not have the ability to move answers...