Esiste un termine per i problemi di prestazioni causati da qualcuno che crea un ciclo che esegue centinaia o migliaia di azioni che avrebbero potuto essere eseguite in blocco?
Il mio esempio è che continuo a correre in loop che attraversano un gruppo di ID e poi eseguono una singola query per ciascun ID per recuperare la riga associata invece di creare una singola query.
Il termine è "Problemi di prestazioni dovuti a cicli eccessivi."
Oppure, se preferisci, l'algoritmo di Schlemiel the Painter .
Seriamente, è semplicemente un problema di prestazioni, un caso di usare un algoritmo improprio. "Needz better Big O."
Il tuo esempio specifico è un "problema N + 1". È comunemente visto negli ORM che i dati "carichi pigri", quando il modello ha una collezione di un oggetto figlio. L'ORM interroga il DB quando un particolare record è assolutamente necessario, quindi prima interrogheranno per un elenco di ID degli oggetti figli (insieme a una query per l'oggetto padre), quindi quando ogni riferimento a un oggetto figlio verrà eseguito l'ORM eseguirà una query quel record specifico, risultante in query N + 1 eseguite per recuperare N oggetti figlio. Il problema è che se sai di aver bisogno di TUTTI i record per i quali hai richiesto, questo comportamento aumenta drasticamente il numero di "round trip" anziché semplicemente "caricando con rabbia" i dati utilizzando una singola query basata sulla relazione FK.
Per quanto riguarda un termine generale per le inefficienze dovute al loop, non ce n'è davvero uno.
Ho sentito problemi simili a questo descritti come "N + 1 problema SELECT".
L'idea è che fai 1 istruzione SELECT per capire quali record devi gestire e poi un altro per ogni singolo record.
Strettamente parlando, questo è per le operazioni SELECT piuttosto che UPDATE, ma sembra piuttosto vicino.
Sembra una comunicazione chunk v chatty.
Chatty = molte chiamate attraverso la rete. Chunky = una chiamata di massa attraverso la rete.
psuedocodarlo:
for each Item in ListOfItems
someNetworkCall(Item)
vs
someMoreEfficientNetworkCall(ListOfItems)
Chiamalo "occasione persa per l'ottimizzazione delle prestazioni utilizzando invece le operazioni di massa".
Naturalmente, ho visto spesso situazioni in cui l'uso di un SQL complesso può migliorare notevolmente le prestazioni, ma il codice risulterà più difficile da mantenere rispetto all'utilizzo di un ciclo e di semplici SQL (e sì, ho anche visto situazioni in cui SQL più veloce sarà essere anche più facile da mantenere rispetto a un ciclo complicato).
Il mio punto è: le prestazioni non dovrebbero essere le uniche, forse nemmeno i primi criteri per decidere quale sia la soluzione migliore, e pensare anche alla manutenibilità. Quando un loop è "abbastanza veloce" e ti dà un codice più pulito, preferisci il ciclo.
Leggi altre domande sui tag loops performance terminology