Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is there a term for performance issues caused by someone creates a loop that performs hundreds or thousands of actions that could have been done in bulk?

My example is that I keep running into loops that loop through a group of IDs and then perform a single query for each ID to retrieve the associated row instead of creating a single query.

share|improve this question

closed as primarily opinion-based by MichaelT, Kilian Foth, GlenH7, Dan Pichelman, gnat Jun 5 '15 at 15:34

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

I've never heard of such a term... maybe "performance degradation due to excessive (or unnecessary) iteration"? – FrustratedWithFormsDesigner Feb 28 '12 at 14:55
Seems like a classic scalability issue to me. – Jesse C. Slicer Feb 28 '12 at 14:59
@JesseC.Slicer: Sort of, maybe? But it also sounds as if the problem would go away if a single bulk operation were performed instead of writing a loop that executes a query on every iteration. I guess you could say that there is a lot of time lost due to context switching (between the client code and DB - every iteration of the loop), but "DB/client context switching" is not very generic, it would only apply in very specific cases. – FrustratedWithFormsDesigner Feb 28 '12 at 15:08
In the DBA Works this is called a "Table Scan" – Morons Feb 28 '12 at 15:22
I call it "bad coding". Everyone can understand it that way :) – Rachel Feb 28 '12 at 15:43
up vote 5 down vote accepted

The term is "Performance Issues Due to Excessive Looping."

Or, if you like, Schlemiel the Painter's algorithm.

Seriously, it's simply a performance problem, a case of using an improper algorithm. "Needz better Big O."

share|improve this answer

Your specific example is an "N+1 problem". It's commonly seen in ORMs that "lazy-load" data, when the model has a collection of a child object. The ORM queries the DB when a particular record is absolutely needed, so they'll first query for a list of IDs of the child objects (along with a query for the parent object), then as each child object is referenced the ORM will query that specific record, resulting in N + 1 queries being executed to retrieve N child objects. The problem is if you know you need ALL the records you have queried for, this behavior drastically increases the number of "round trips" as opposed to simply "eager-loading" the data using a single query based on the FK relationship.

As far as a general term for inefficiencies due to looping, there really isn't one.

share|improve this answer

I've heard problems similar to this described as an "N+1 SELECT issue".

The idea being that you make 1 SELECT statement to work out which records you need to deal with, and then another for each individual record.

Strictly speaking of course, this is for SELECT operations rather than UPDATE, but it seems pretty close.

share|improve this answer

Sounds like chunky v chatty communication.

Chatty = lots of calls across the network. Chunky = a bulk call across the network.


for each Item in ListOfItems


share|improve this answer

Call it "missed occasion for performance optimization by using bulk operations instead".

Of course, I have often seen situations where using one complex SQL can improve performance greatly, but will result in code harder to maintain than using a loop and simple SQLs (and yes, I have also seen situations where the faster SQL will be also easier to maintain than an overcomplicated loop).

My point is: performance should not be the only, perhaps not even the first criteria for deciding which solution is better, also think about maintainability. When a loop is "fast enough" and gives you cleaner code, prefer the loop.

share|improve this answer

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