Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Some code works but it runs an unnecessarily large fraction of the code in many cases, though that extra code is still required sometimes. Better preprocessing, simple stoppers and conditional checkers would save enormous amount of running time. What is the technical jargon to describe unnecessary running where a programmer could simply place a condition or do better preprocessing?

share|improve this question

closed as off-topic by gnat, MichaelT, Bart van Ingen Schenau, Dan Pichelman, Robert Harvey Nov 21 '13 at 22:38

  • This question does not appear to be about software development within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

Or ... inefficiency. –  Useless May 8 '13 at 21:04
I like to think of it as energeticness. –  psr May 8 '13 at 21:05
In my experience this has always been called "source code" –  Jimmy Hoffa May 8 '13 at 21:11
I've heard "code bloat" a lot. –  imel96 May 28 '13 at 2:39
"What is the name of this thing" questions are off-topic. These are poor questions for the same reasons that "identify this obscure TV show, film or book by its characters or story" are bad questions: you can't Google them, they aren't practical in any way, they don't help anyone else, and allowing them opens the door for the asking of other types of marginal questions. See Also Let's Play the Guessing Game –  gnat Nov 21 '13 at 1:07

6 Answers 6

up vote 14 down vote accepted

I think you've hit on an important question. We don't have good words to describe unnecessary computation.

One word is "bottleneck". That seems to describe something localized, that traffic has to get through, and limits the speed. The trouble is, in decades of performance tuning, I've found and fixed numerous problems, and none of them fit that image. Sure, you may be able to find such a thing in a communication network, but that's only one particular kind of system.

I just call them "speed problems", "speed bugs", "slowness bugs" (slugs), or "speedup opportunities". If it weren't so many syllables, I think the best word would be "speedup opportunity", because the other terms have negative connotations. The negative connotations cause people to instinctively reject the idea that their code might have them. That, together with not knowing how to search for them, causes them not to be found, resulting in much code being much slower than it could be.

In fact, speedup opportunities can be perfectly defensible state-of-the-art code, with good big-O algorithmic performance. What makes it a speedup opportunity is that it's responsible for a healthy fraction of total wall-clock elapsed time, and it can be done in a way that takes a lot less time, or possibly avoided altogether.

What is amazing about these things is, if the code is industrial-strength (not a toy), there can be one opportunity of a certain size, then a less big one, then a still less big one, and so on. Finding and fixing one gives you a certain satisfying speedup, but it also makes the others bigger, as a percentage. This picture shows fixing six of them. Even as they more-or-less decrease in size, the speedup grows exponentially: enter image description here
So if you keep going, finding the next, and the next, and the next, you can achieve phenomenal speedup, until the code is really tightly tuned. Of course, you'd better not miss any, or you won't get that result. This is the point I want to get across.

In order to find these opportunities, don't just "measure, measure". Measuring does not find them. If you think of them as bugs (and everybody makes bugs) they are actually very easy to find. Many of them take the form of avoidable function calls, and the time they take is exactly what exposes them.

Here's one example of what I mean.

share|improve this answer
@Masi: It is an important topic, and the tools that are being developed can't compete with the best tool that's been around forever, a debugger, and here's the math behind it. Most of the programming world is still under the false impression that the way to find inefficiencies is by measuring. All that can tell you is where they're not, not where they are. It leads people to be happy with finding small problems but missing big speedup opportunities. –  Mike Dunlavey Nov 17 '13 at 16:29
The word to describe "unnecessary computation" is "bad programming." We don't have fancy words describe bad UI's or bad database design, because "bad" is good enough. –  DougM Nov 20 '13 at 4:35
You say "Measuring does not find them", and then give us a link to another answer you wrote as an example that finds them by measuring. Which is it? Measure, or don't measure? –  Michael Shaw Nov 20 '13 at 6:33
@MichaelShaw: Just to be specific, I've seen an app that takes about 60 seconds to start up. It happens to be spending about 50% of that time reading resources from dll files (which a CPU profiler will not see at all). Profilers that summarize function times will show many functions with high inclusive time. (Self time is useless.) Looking at that, you have no idea what the problem is. However, if you interrupt it a few times and each time understand the reason why (by reading the 20-level stack) you see it's doing it only for eye-candy on a splash screen. ... –  Mike Dunlavey Nov 20 '13 at 20:27
That's a very good example, thanks. –  Michael Shaw Nov 20 '13 at 20:35

It's simply referred to as inefficient.

Efficiency/performance: the amount of system resources a program consumes (processor time, memory space, slow devices such as disks, network bandwidth and to some extent even user interaction): the less, the better. This also includes correct disposal of some resources, such as cleaning up temporary files and lack of memory leaks.

Programming languages are computer algorithms that consume processor resources. The efficiency of using that resource is the measurement of the source code's performance.

Algorithmic Efficiency

share|improve this answer

The term that I prefer is Negatively optimised code. Negatively optimised code that forces the processor and/or I/O systems to jump through a number of programmer-created hoops that in no way change the business correctness of the code.

Negatively optimised code may be created for any number of reasons. Some good and some bad. Sometimes even following good design patterns may result in negatively optimised code. Most of the time though negatively optimised code is created because efficient processing, storage and transfer of data is less important than some other business goal. As software is a game of priorities, negatively optimised code isn't necessarily bad.

One example of negatively optimised code might be for an application to use a database for storing business specific constants that do not change. Another example might be the use of a linked list for a small list of items that need to be accessed randomly. In both of these cases, the difference in speed between optimised and negatively optimised code may not be large enough to warrant fixing at the cost of fixing other bugs or adding new functionality.

It would be impossible to find a programmer who has never written negatively optimised code. We've all done it.

share|improve this answer

"Surplus Runtime Memory Consumption" is the expression what would describe the situation you have described in your question. When a large fraction of the code is running (when not needed), it obviously occupies large fraction of memory unneccsarily. As a consequence, surplus or extra amount of memory is consumed that can be avoided by via good program design and logic.

share|improve this answer

It can be described as code that has a big overhead, much is done in order to attain its purpose.

From Wikipedia: In computer science, overhead is any combination of excess or indirect computation time, memory, bandwidth, or other resources that are required to attain a particular goal. It is a special case of engineering overhead.

I have a quarrel with "required" in that description, since overhead can be reduced, it was not really required in the first place.

Lots of stoppers and conditionals make code either restricted to specific scenarios, or more complex. You are trading either a simpler or more generic implementation with a big overhead for a more complex and more specific implementation with smaller overhead.

share|improve this answer

Non - Scalable – I recently ran into this issue where a lot of code was run doing nothing on a set of data under most circumstances. This worked fine dealing with 200 rows of data but when dealing with 20,000 rows of data the time to loop and inspect unchanged data took to long. Do not write Non-Scalable code.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.