Inefficient Coding vs. Efficient Coding

[FallenHero]

So, I've been wondering about this for awhile and I keep seeing various posters talk about how certain games are poorly coded, inefficient code, ect. What would be the main difference between a poorly coded game/program vs. a good one? Can you provide a simple example. Is it error handling, is it the sheer number of lines, is it making sure it isn't constantly jumping around. I just want to understand it better.

 

[Markbnj]

Efficient code is minimal, complete, and cohesive.

 

[DaveSimmons]

By poorly coded for games people usually mean one or both of:
1. Not sufficiently debugged
2. Not appropriately optimized

Users have no idea (and usually shouldn't care) whether code is elegant or efficient.

1. Not sufficiently debugged

a. memory and resource leaks ( = eventual crashes)
b. other crash bugs
c. scripting / quest bugs
d. save data corruption


2. Not sufficiently optimized

This is where they say "sloppy coding", "lazy console port", "inefficient" though they don't really know what they're saying. Sloppy, lazy, inefficient, ugly spaghetti code is just fine for 90% of an application (for the user experience) as long as it's sufficiently debugged.

There is usually less than 10% of a program where speed is actually noticeable and that is where optimizing for speed matters. Some parts of the graphics engine, the physics engine, and the AI need to run as fast as possible.

Even there, efficient code may mean choosing the right algorithms more than writing elegant code. A sloppy quicksort (that's bug-free) will usually beat the most elegant bubble sort for large enough lists.

 

[Cogman]

Originally posted by: Markbnj
Efficient code is minimal, complete, and cohesive.

I somewhat disagree. I believe efficient code is code that does whatever task it is given the fastest. In some cases that is neither minimal or cohesive. (Though in many cases it is minimal and cohesive).

Good coding and efficient coding are different things. Good code involves good coding practices, it involves code that is easily maintainable, easy to read, and understand. Often, good code results in less code then poor coding designs.

When someone says that a game is poorly coded. They are usually referring to bugs or slugs (game crashes or it runs slower then it should). They can be introduced in many ways, perhaps there is a major memory leak, perhaps it just came from flawed logic. Heck, it could have been done from something so simple as passing an object by value when by reference was ment.

However, one metric of code quality that I have never heard is number of lines of code. Good code can be 10000 lines long or 10 lines long. Length has little to do with whether code is well written or not.

 

[DaveSimmons]

Note that little of what I said applies to business application development, where a factor like maintainability of the code over many years is much more important than maintaining a solid 60 fps with soft shadows for the accounting screen

 

[GodlessAstronomer]

The funny thing about game code is that despite the fact that some of the smartest people in the industry are working on it, it's quite often some of the ugliest and least elegant code out there. The reason for this is simple - in games, performance matters. This is one of the few areas in the industry where you actually need to be concerned that polymorphic method calls are actually slightly slower than direct calls, or that indirection through a data repository is slower than no indirection. Those precious milliseconds add up when you need to make thousands of complicated calls dealing with collision detection, path finding and complex geometric equations, and you need to do it 30-60 times a second.

 

[FallenHero]

Originally posted by: DaveSimmons
Note that little of what I said applies to business application development, where a factor like maintainability of the code over many years is much more important than maintaining a solid 60 fps with soft shadows for the accounting screen

By maintainability do you mean proper notations within the code, a good documentation of the language used, and a history of changes? Or is it simply a matter of making sure the code is easy to follow and read, should someone with little knowledge decide to try to change something.

 

[brandonb]

I will use Falcon4 (a game released in 1998) as an example.

When it was first released, it had the ability to load up HARM missiles. Those missiles had it's own radar-detecting interface. Which would show up on the Jet's internal screens to display to the pilot. When in HARM missile mode, the game ran at like 5 fps, when you were not in HARM mode, it would run at like 20 fps.

Obviously there was a problem there. Why?

The first obvious answer was in this game every single tank, airplane, helicopter, infantry guy was simulated on the battlefield, maybe 20,000+ objects in the game world.

My guess is when the HARM missile mode was on, it would loop through those 20,000 objects every frame doing something like this:

if your.radarmode = HARM then
..For each object in battlefield
....if object.type = RADAR then
......add to HARM display
....end if
..next
end if

Sure, the code is small, compact, hard to screw up, but you are looping through every object in the battlefield looking for a radar. That takes alot of CPU power. A radar object is rather quite static, they just don't change that often, only if a new radar site appeared, so why would you need to check that every single time?

Why not just loop through the battlefield objects once when the mission loads, and build a list of radar objects. That way you'd loop through maybe 20 objects vs 20,000 every single frame.

But that code would be much larger as you are basically creating an index of objects in your code. (In database terms)...

That's just an example of inefficient coding.

 

[Markbnj]

I somewhat disagree. I believe efficient code is code that does whatever task it is given the fastest. In some cases that is neither minimal or cohesive. (Though in many cases it is minimal and cohesive).

Efficient != fastest in all cases, though. In many cases efficient means small, or it may very well mean fast, or both.

 

[Nothinman]

So, I've been wondering about this for awhile and I keep seeing various posters talk about how certain games are poorly coded, inefficient code, ect. What would be the main difference between a poorly coded game/program vs. a good one? Can you provide a simple example. Is it error handling, is it the sheer number of lines, is it making sure it isn't constantly jumping around. I just want to understand it better

As DaveSimmons says, if the game is properly debugged and there's little in the way of big bugs most people will think it's fine. A whole game will consist of hundreds or thousands of seperate functions written by many different people so it's impossible to judge all of it in one lump.

Number of lines doesn't matter so much because the compiler will do it's own optimizations regardless. You could have 2 functions that do the same thing in a totally different number of lines and the compiler might be able to optimize both down to the same assembly code.

However, one metric of code quality that I have never heard is number of lines of code. Good code can be 10000 lines long or 10 lines long. Length has little to do with whether code is well written or not.

By itself LOC isn't a good metric, however within context it can be. If you know a particular job within a particular language should take between 10 and 20 lines but the function you were given is 100 lines it should probably considered suspect.

By maintainability do you mean proper notations within the code, a good documentation of the language used, and a history of changes? Or is it simply a matter of making sure the code is easy to follow and read, should someone with little knowledge decide to try to change something.

Both. You can't expect someone who's only ever worked with Java or VB to jump into the Quake3 source and know what's going on. But someone who has experience with game programming in C and assembly should be able to look at it and have some idea what's going on.

 

[degibson]

Originally posted by: GodlessAstronomer
The funny thing about game code is that despite the fact that some of the smartest people in the industry are working on it, it's quite often some of the ugliest and least elegant code out there...

Its a classic disconnect between languages and performance. Languages are made to be elegant, intuitive, easy to code. Performance is always an afterthought -- literally. The least elegant parts of C/C++ are often the most performance-critical (e.g., threading, volatility, atomics, prefetching, the dreaded goto).

 

[veri745]

Originally posted by: Cogman

However, one metric of code quality that I have never heard is number of lines of code. Good code can be 10000 lines long or 10 lines long. Length has little to do with whether code is well written or not.

However, if you can condense 10k lines of code into 10 lines (or more realistically, 10000 -> 1000), if no functionality is lost, I'd confidently say that the long version is poorly coded.

These types of optimizations (for readability and/or maintenance) are a large part of my job. Well written code generally doesn't balloon like that over time.

*edit* of course I'm talking about functional lines of code, not formatting or comments.

 

[KIAman]

This question does not have a single answer because of the ambiguity of the word "efficiency" without related context.

The following must be defined.

1. Define the word "efficient code"
2. For which programming paradigm?
- Imperative
- Functional
- Logical
- Object-oriented
3. Size of project
4. Time constraint
5. Maintainability requirement
6. Performance requirement
- Within what environment?
- Coupling to what system(s)?

Everyone and their cousins will have their own opinions on what makes generally "efficient" code but the answer changes depending on the initial information.

What does efficient coding mean to me? I work in an agile based development environment which stresses engineering, documentation and maintainability. Efficient coding for me means easily readable and maintainable code at the cost of performance.

 

[SJP0tato]

Originally posted by: KIAman Efficient coding for me means easily readable and maintainable code at the cost of performance.

With a few years in the industry now, I agree 100% with this.

In my experience it is much easier to try to get 100% of the code to stick to these standards, and only optimize the pieces that then need it. This works much better than trying to optimize everything, then go back and make it readable/maintainable.

 

[Modelworks]

I define it with two things:

1. Size - I often work with hardware that has very little room for extra bits of code. Sometimes 16Kb is all there is for program storage, 16Kb for data and 16Mhz for clock speed. In that environment you have to be very efficient, meaning if you are not , then chances are the program just will not work because it can't fit in the available space. The same could apply for a game that used code that used too much memory for the data to stay in memory and so it swaps out from a hard drive , not because the program couldn't work any other way, but the programmer chose that method for whatever reason.

2. Performance - Can coincide with 1. If I write a program like 1+1=2 . And that is the entire program and I have 2Ghz of cpu time to do that, I can write the slowest code, most loops , do whatever and still get that to execute fine. If I need to create something complex, like a game, and I know that it could be done and run fine on a 2GHz cpu , but instead decide I'm not going to optimize it or change how I do things, they can just get a faster cpu, that would be inefficient, which is often what people see when games are ported from a console to a pc. Yes the pc has better hardware but the programmer doesn't take the time to make use of it. The result can be something that takes a monster of a pc to run yet isn't better than a game with the same amount of content but using half as much pc power.


A good example of this is emulators. If you emulate some of the console games on a pc they can run slow, the same game written in native code for the pc runs normal. The end product is the same but because the former had to go through emulation code it was inefficient.


I think readability of code is a totally different subject. If the programmer(s) understand the code then efficiency can be very high.

 

[Ken g6]

There's also a tradeoff between code efficiency and coder efficiency. If I spend 24 hours shaving 1 hour off a job that takes 24 hours, but the job runs only once a month, it's going to take 2 years to break even on time. And that's assuming computer time is worth as much as programmer time. (Computer time is much cheaper, as long as it doesn't cut into some other employee's time.)

 

[CycloWizard]

Originally posted by: Ken g6
There's also a tradeoff between code efficiency and coder efficiency. If I spend 24 hours shaving 1 hour off a job that takes 24 hours, but the job runs only once a month, it's going to take 2 years to break even on time. And that's assuming computer time is worth as much as programmer time. (Computer time is much cheaper, as long as it doesn't cut into some other employee's time.)

I spent two months shaving 25 microseconds off of some code, but the code had to run that much faster or the project was a bust. It's only mildly ridiculous.

 

[chronodekar]

I wish I was around earlier.

FallenHero,

I do not have any experience with game programming,but I believe that what defines good and efficient code to the be same regardless of the application.

The efficiency of any code is best graded from the end-user.
Does it do what the user wants? If yes, then you have working code.
Does it do the job well? If yes, then you have efficient code.

For example, if you make a game that runs and plays on a person's system, then you have working code. If it runs at less than 5 frames per second, then you have very inefficient code.


Now, what makes a program poorly coded or not? In my college days and into my first job, I believed it was what Mark describes it,

Efficient code is minimal, complete, and cohesive.

Now, I'm not that sure anymore. Instead, I feel it's more depends on who all are part of your team. (present + future members) If whoever reads your code, instinctively knows/figures out how it works, then I say you have very well written code. As long as your program is efficient, I don't think it matters if it's 10000 lines or even a 100 lines.

What matters is that the next ####### who has to work on your code should be able to get started within less than an hour. (or at least, very quickly)

There are times when I feel that it's probably better to write more lines of code so that others in the company can easily understand it, rather than to write less and spend a week in e-mail correspondence explaining it all. (Assuming that program efficiency is not lost)

 

[degibson]

Originally posted by: chronodekar

What matters is that the next ####### who has to work on your code should be able to get started within less than an hour. (or at least, very quickly)

I hate unreadable code as much as the next person. But in general, readable != efficient. They're not mutually exclusive, but they're not automatically the same thing. Ideally, good code is readable and efficient.

Since we've been down the 'what is readable' path before, and the 'code for the weakest coder' path too, I'll just throw in my ad-hoc, subjective definition of efficient code and call it a day.

Efficient code is not wasteful. It does not waste instruction memory with needless bloat, data memory with needless overhead, CPU with needless computation, etc.. Note the strong emphasis on needless. That is: big, slow, ugly code can still be efficient if its big-ness, slow-ness, and uglyness are needed to get the job done.

I know I'm opening a can of worms by saying this... but ... efficiency and readability are sometimes at odds. E.g., A recursive tree traversal is more readable but less efficient than a loop-based traversal. Three nested for loops for a bubble sort is more readable but less efficient than, say, a radix sort. Etc. There are many examples.

 

[chronodekar]

Originally posted by: degibson
Since we've been down the 'what is readable' path before, and the 'code for the weakest coder' path too, I'll just throw in my ad-hoc, subjective definition of efficient code and call it a day.

Brings a smile to my face when I remember those threads.

I know I'm opening a can of worms by saying this... but ... efficiency and readability are sometimes at odds.

You and I seem to keep saying the same thing in different words. If I had to prioritize, then it's more important to get the code efficient first. Or at least, to the point of user-satisfaction. A very close second is making it readable.

When I code, I try to do both, but when the 2 are at odds, then, I'd rather take efficiency. (And litter the code with comments)

Now, writing good comments, that is a totally different discussion and a REAL can of worms!!!

 

[Cogman]

Originally posted by: degibson

Originally posted by: chronodekar

What matters is that the next ####### who has to work on your code should be able to get started within less than an hour. (or at least, very quickly)

I hate unreadable code as much as the next person. But in general, readable != efficient. They're not mutually exclusive, but they're not automatically the same thing. Ideally, good code is readable and efficient.

Since we've been down the 'what is readable' path before, and the 'code for the weakest coder' path too, I'll just throw in my ad-hoc, subjective definition of efficient code and call it a day.

Efficient code is not wasteful. It does not waste instruction memory with needless bloat, data memory with needless overhead, CPU with needless computation, etc.. Note the strong emphasis on needless. That is: big, slow, ugly code can still be efficient if its big-ness, slow-ness, and uglyness are needed to get the job done.

I know I'm opening a can of worms by saying this... but ... efficiency and readability are sometimes at odds. E.g., A recursive tree traversal is more readable but less efficient than a loop-based traversal. Three nested for loops for a bubble sort is more readable but less efficient than, say, a radix sort. Etc. There are many examples.

No can of worms, I think it is expected that faster code doesn't always mean clean code.

In the the case of fast code though, I would say that comments are a MUST. Heck, even if there are more comments then code, if it is able to bring readability up then it is worth it. (Though, I guess there is no point in trying to explain calculus in code comments )

One thing to note, though, even though a bubble sort is readable, there is still code that is better and more readable then it. IE a selection sort or an insertion sort. Yes they are both n^2, however, they are generally faster then a bubble sort in execution speed while being just as readable.

So while I agree that it is often the case that readability and efficiency are at odds with each other (especially in the case of trying to jump efficiency classes. It is very rare to find a faster efficiency class that has code less complex then the slower efficiency class). There are some examples where it isn't the case.

 

[degibson]

Hmm... I agree with chronodekar and Cogman. This must be an Anandtech Programming Forum first. Savor the flavor, colleagues.

 

[Markbnj]

Originally posted by: degibson
Hmm... I agree with chronodekar and Cogman. This must be an Anandtech Programming Forum first. Savor the flavor, colleagues.

Tastes like chicken .

For my part, I think readability is less elastic than efficiency. Readbility might be improved or degraded, but for the most part if a person can read code and takes the time then they can come to understand a program. Readability is also somewhat subjective, whereas although the metric might change with the project, there is probably always some measurable definition of efficient.

 

[EricMartello]

In a nutshell, efficient code gets the most done while using the least amount of system resources...or you say a function produces a result using the fewest computational cycles as is possible.

To that end, this is where my general disdain for sandboxed languages, frameworks and other McProgrammer "tools" comes from, as the resulting program produced by these IDEs is generally full of unnecessary bloat and tied to craploads of external dependencies. It's largely limited to Windows, and the disconnect between the underlying computer hardware and the programmer gets wider with each new revision of these tools.

By the same token, a bad programmer will still produce crap code using a pure languages like ASM or C++ if they don't know how to properly allocate and manage resources...so for a bad to mediocre programmer, using McProgrammer tools would be the lesser of two evils since they often handle resource management for you (the same way mommy used to wipe your butt and feed you).

 

[Cogman]

Originally posted by: EricMartello
In a nutshell, efficient code gets the most done while using the least amount of system resources...or you say a function produces a result using the fewest computational cycles as is possible.

To that end, this is where my general disdain for sandboxed languages, frameworks and other McProgrammer "tools" comes from, as the resulting program produced by these IDEs is generally full of unnecessary bloat and tied to craploads of external dependencies. It's largely limited to Windows, and the disconnect between the underlying computer hardware and the programmer gets wider with each new revision of these tools.

By the same token, a bad programmer will still produce crap code using a pure languages like ASM or C++ if they don't know how to properly allocate and manage resources...so for a bad to mediocre programmer, using McProgrammer tools would be the lesser of two evils since they often handle resource management for you (the same way mommy used to wipe your butt and feed you).

This I disagree with. Every language has its place. Some are better then others for said place, but not all.

You don't need a jack hammer to pound in a nail, similarly while you could move a mountain with a shovel, why would you want to?

90% of people already have the .net framework installed. Creating a windowed application with say c# is really simple and easy. Sure it will render at 392 fps and not 5000, but who cares?

You'd have to be insane to actually want to program windows applications using straight Win32 calls (Though, I think every programmer should have to actually know how to do that. The knowledge of whats going on underneath is an important one)

Though, I do cringe everytime there is a clear example of the "Wrong tool for the wrong job." IE Frets on Fire. That game should be able to render 100x faster then it does, but they used python of all languages to create it.. Sorry, but games nearly demand c++, or some lower level language then python.