Term for Performance Issues Due to Looping

Question

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.

Answer 1

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."

Answer 2

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.

Answer 3

Sounds like chunky v chatty communication.

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

Psuedocode:

for each Item in ListOfItems
 someNetworkCall(Item)

versus

someMoreEfficientNetworkCall(ListOfItems)

Answer 4

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.

Answer 5

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.