Al final de 08-01 vam substituir un bucle while read per un únic awk afirmant que era «més ràpid». És una afirmació còmoda i molt repetida, però mentre no hi hagi un número al costat no és enginyeria, és folklore. Aquesta lliçó va de números: com es mesuren de debò els temps d'un script, què és el que de veritat costa car en Bash —i no és el que la majoria es pensa—, quines optimitzacions tenen un efecte mesurable i quines són superstició, i sobretot quan s'ha de deixar d'optimitzar. Al final perfilarem informe-diari.sh sobre un CSV de 500.000 enviaments i reduirem el seu temps d'execució de minuts a segons, mesurant abans i després.

1. Primer mesurar, després optimitzar
2. Les tres maneres de mesurar: time, SECONDS i date +%s%N
3. El cost dominant en Bash: crear processos
4. Builtins davant d'ordres externes
5. Canonades inútils i llegir el fitxer una sola vegada
6. El cost ocult de les subshells
7. Acumular la sortida i escriure un sol cop
8. while read, mapfile o awk: quan cadascun
9. Paral·lelitzar de debò, i quan no serveix
10. LC_ALL=C, memòria i el criteri final
11. Aplicació: perfilar informe-diari.sh

Hi ha tres raons per no optimitzar sense mesurar. La primera és que la intuïció falla: gairebé tothom es pensa que el bucle és lent per ser un bucle, quan en realitat ho és pels dos cut que hi ha a dins. La segona és que optimitzar costa llegibilitat, i acabes de dedicar una lliçó sencera a guanyar-la; pagar-la a canvi d'un 2 % de millora és un mal negoci. La tercera és que el 90 % del temps sol estar en el 10 % del codi: si no saps quin és aquest 10 %, optimitzaràs la resta.

El mètode és sempre el mateix, quatre passos:

1. Estableix la línia base. Mesura l'script tal com està, sobre dades representatives.
2. Localitza el punt calent. Mesura per parts fins a saber quin bloc s'emporta el temps.
3. Canvia una sola cosa i torna a mesurar en les mateixes condicions.
4. Atura't quan ja n'hi hagi prou. Si l'informe diari ja triga 4 segons i s'executa un cop al dia, baixar-lo a 2 no li serveix a ningú.

I una advertència sobre les «dades representatives»: mesurar amb el CSV de proves de 50 línies no diu absolutament res. Moltes optimitzacions només es noten a partir d'una certa mida, i algunes —carregar el fitxer en memòria— són bones amb 1.000 línies i catastròfiques amb deu milions.

Les tres xifres expliquen històries diferents i saber-les llegir és mitja lliçó:

La combinació diagnòstica és aquesta: si user + sys és molt inferior a real, l'script està esperant (disc, xarxa, un sleep) i optimitzar el codi no servirà de res. I si sys és alt i comparable a user, com a l'exemple, el culpable gairebé sempre és la creació de processos: 24 segons dins del nucli no els gasta un càlcul, els gasta un fork per línia.

Compte amb un detall: time és una paraula clau del shell i una ordre externa (/usr/bin/time), amb sortides diferents. La del shell és la que has vist; l'externa, amb -v, hi afegeix la memòria màxima utilitzada, que és molt útil. Per mesurar parts d'un script, dues eines ja conegudes:

SECONDS és gratis (és intern) però només dóna segons sencers: serveix per a blocs llargs. date +%s%N dóna nanosegons i serveix per a blocs curts, tot i que crea un procés per mesura, així que no el posis dins del bucle que estàs mesurant. I una regla de laboratori: repeteix la mesura tres cops i queda't amb la mediana. La primera execució omple la memòria cau de disc i sempre és la més lenta; comparar una primera execució amb una tercera és la manera més habitual de «demostrar» una millora inexistent.

Aquesta és la idea de la lliçó. En Bash, executar una ordre externa implica que el nucli dupliqui el procés (fork), carregui el binari (exec), resolgui les seves biblioteques i el destrueixi en acabar. Això costa de l'ordre d'1 a 3 mil·lisegons. Sembla res, fins que ho multipliques pel nombre de línies d'un fitxer.

Comparem tres maneres d'extreure la ciutat (camp 3) de cada línia d'un CSV de 500.000 enviaments:

Els temps mesurats sobre el mateix fitxer i la mateixa màquina:

Un milió de processos per llegir mig milió de línies. La versió A no és «una mica més lenta»: és inviable. I fixa't que la diferència entre A i B no és el bucle, que és el mateix, sinó haver tret els dos processos de dins. Aquesta és la primera regla operativa: mai executis una ordre externa dins d'un bucle que recorre línies. Si la necessites, probablement el bucle sencer hagi de ser un awk.

Corol·lari de l'anterior: quan el shell pot fer alguna cosa per si mateix, fes-la amb ell. type -a (01-04) et diu quin és quin.

Aquí convé una dosi d'honestedat: fora d'un bucle, això és irrellevant. Canviar un basename solt per ${f##*/} estalvia dos mil·lisegons en tot l'script i pot empitjorar la llegibilitat per a qui no domini les expansions. La taula importa dins dels bucles, on l'estalvi es multiplica pel nombre de voltes. Optimitza l'interior dels bucles i deixa l'exterior llegible.

Cada | d'una canonada és un procés més. La majoria de les canonades llargues que es veuen en producció tenen etapes que sobren:

El cas del cat inútil fins i tot té nom (useless use of cat). Però l'error més car no és comptar processos: és llegir el mateix fitxer diverses vegades. Aquest patró apareix a tots els scripts d'informes:

La primera versió llegeix 500.000 línies quatre vegades; la segona, una. Al toolkit real això va baixar el bloc d'estadístiques de 3,2 s a 0,8 s. I la versió d'una passada és, a més, més consistent: si el fitxer canvia mentre s'executa, les quatre xifres de dalt poden no quadrar entre si.

$( ) crea una subshell, que és un procés fill amb tota la seva memòria copiada. Costa el mateix que llançar una ordre externa, encara que a dins no n'hi hagi cap:

El mateix passa amb les canonades: cmd | while read ... executa el while en una subshell, i per això les variables que modifiques a dins no existeixen en sortir —el problema clàssic que vam resoldre a 05-05 amb done < <(cmd)—. Allà la substitució de procés no és només qüestió de correcció: també estalvia un procés.

Un truc útil per a blocs que escriuen molt: en lloc d'agrupar amb ( ... ) > sortida.txt, que crea subshell, agrupa amb claus, que no la crea:

Cada >> dins d'un bucle obre el fitxer, escriu i el tanca. Amb 500.000 voltes són 500.000 obertures:

Les tres produeixen el mateix fitxer; la tercera és la més ràpida, la més curta i la que menys memòria fa servir, perquè el descriptor s'obre un cop i el bucle escriu al flux (05-05). Mesurat amb 200.000 línies: 4,1 s la primera, 0,9 s la segona, 0,7 s la tercera.

La regla pràctica, en una frase: si dins del while només filtres, comptes o sumes, el teu bucle és un awk mal escrit. El while read es justifica quan cada línia dispara accions que awk no sap fer bé —llançar un curl per enviament, invocar funcions del shell, escriure en fitxers diferents—; i tot i així convé preguntar-se si awk pot generar la llista i el bucle limitar-se a actuar-hi.

Quan la feina és independent per element i cadascun triga de debò —consultar l'API per cada ciutat, comprimir cada rotat—, la paral·lelització és la millora més gran disponible. Amb xargs -P (05-01) o amb &/wait (05-02):

Dues advertències imprescindibles. La primera: si el coll d'ampolla és el disc, paral·lelitzar empitjora les coses. Vuit processos llegint alhora d'un disc mecànic generen cerques aleatòries i poden trigar més que un de sol; en SSD l'efecte és menor però el límit hi és igualment. Mira el time: si real és alt però user + sys és baix, estàs esperant E/S i més processos no t'ajudaran. La segona: els processos paral·lels escriuen entremesclat; que cadascun escrigui al seu propi fitxer i es consolidi al final, com feia flota.sh a 07-06. Un punt de partida raonable per al grau de paral·lelisme és -P "$(nproc)" en tasques de CPU (06-03), i força menys en tasques de disc.

Un accelerador que gairebé ningú no coneix: la configuració regional. Amb ca_ES.UTF-8, sort i grep apliquen regles d'ordenació i classes de caràcters multibyte; amb LC_ALL=C comparen byte a byte.

Quatre vegades més ràpid per una variable. La condició és que l'ordre byte a byte et serveixi: per a claus internes, identificadors o camins, sí; per a una llista de ciutats que veurà un humà, no, perquè Àvila acabarà fora de lloc. Al toolkit s'aplica als ordenaments intermedis i es deixa la configuració regional a la presentació final.

Sobre la memòria, una regla simple: no carreguis en memòria el que pots recórrer en flux. mapfile -t linies < /var/log/veloz/acces.log amb un registre d'un gigabyte intenta reservar més d'un gigabyte de RAM —els arrays de Bash tenen força sobrecàrrega per element— i pot acabar amb el procés mort pel gestor de memòria del nucli, de matinada i sense explicació. Els fluxos (while read, canonades, awk) fan servir memòria constant independentment de la mida del fitxer.

I el criteri final, el més important de tots: saber quan el problema ja no és de Bash. Senyals concrets que has arribat al límit:

• Després d'aplicar tot l'anterior, l'script continua trigant minuts.
• El gruix de la lògica ja és dins d'un awk de quaranta línies amb la seva pròpia estructura de dades.
• Necessites estructures que Bash no té: nombres en coma flotant de debò, arrays de dues dimensions, JSON imbricat que jq ja no cobreix amb comoditat.
• Necessites creuar dos fitxers grans per una clau, ordenar per diversos criteris o consultar històric: això és una base de dades, encara que sigui SQLite.
• L'script passa de 500 línies i la seva lògica de negoci importa més que la seva lògica de sistema.

Bash és excel·lent enganxant ordres del sistema; és mal llenguatge per a càlcul intensiu. Reconèixer-ho a temps és una decisió tècnica, no una derrota: informe-diari.sh continua sent Bash, però si demà cal creuar enviaments amb facturació i històric de tres anys, aquest tros s'escriu en Python o en SQL i Bash l'orquestra.

Generem un CSV representatiu i mesurem la línia base:

sys gairebé igual que user: el diagnòstic de l'apartat 3 és immediat, això són processos. Instrumentem l'script amb SECONDS al voltant de cada bloc per localitzar el punt calent:

Dins del bloc de 188 segons hi havia un while IFS=, read amb un cut i un date -d per línia (un milió de processos) més quatre grep -c posteriors sobre el fitxer complet. Els tres canvis aplicats, en aquest ordre i mesurant-ne cadascun:

De 192 segons a 3,9: quaranta-nou vegades més ràpid sense canviar ni una línia de la lògica de negoci, només on s'executa cada cosa. I aquí s'aplica el pas 4 del mètode: parem. Queden 3,9 segons, dels quals 2 són l'enviament del correu, que depèn de la xarxa. Continuar optimitzant un script que s'executa un cop al dia a les 06:30 no aporta res a ningú.

• Optimitzar sense línia base. Sense el número de partida no pots demostrar la millora ni detectar que has empitjorat les coses. Anota el time inicial abans de tocar res.
• Mesurar un sol cop. La primera execució paga la memòria cau de disc freda. Executa tres cops i fes servir la mediana; per comparar de debò, hyperfine automatitza justament això.
• Micro-optimitzar fora dels bucles. Canviar basename per ${f##*/} en una línia que s'executa un cop no estalvia res i pot restar claredat. L'interior dels bucles és on es guanya.
• Confondre «menys línies» amb «més ràpid». Una canonada de sis etapes és curta d'escriure i crea sis processos; un awk de tres línies en crea un.
• Paral·lelitzar una feina limitada pel disc. Si real és alt però la CPU està ociosa, més processos només afegeixen contenció.
• Consell: set -x amb PS4 fa de perfilador pobre. Amb PS4='+ $(date +%s.%N) ' cada línia de traça (05-03) queda marcada amb el seu instant i veus els salts de temps.
• Consell: l'optimització més rendible sol ser no fer la feina. Abans d'accelerar el processament de tot l'històric, pregunta't si cal processar més que el dia en curs.

Exercici 1. Aquest bloc triga 2 minuts amb 300.000 línies. Identifica els tres problemes de rendiment i reescriu-lo en una sola passada.

Exercici 2. Escriu una funció veloz_mesura que executi una ordre tres cops, mostri el temps real de cada execució en mil·lisegons i la mediana, fent servir date +%s%N.

Exercici 3. Un script triga real 5m10s, user 0m12s, sys 0m8s. On és el temps i quina optimització té sentit? I si fos real 5m10s, user 2m40s, sys 2m20s, què buscaries?

Solució 1.

Els tres problemes. (1) Complexitat quadràtica: per cadascun dels 300.000 identificadors es fa un grep que recorre el fitxer sencer; són 9×10¹⁰ comparacions de línia. És el defecte greu, i desapareix en recórrer el fitxer un cop en lloc de buscar-hi a dins. (2) Processos dins del bucle: grep, echo, cut, expr i bc són cinc processos per volta, un milió i mig en total. (3) for sobre una substitució d'ordres, que a més de crear la subshell construeix en memòria una cadena amb els 300.000 identificadors i la parteix pels espais. La versió d'awk fa una passada, un procés i suma en coma flotant de manera nativa, sense bc (06-01).

Solució 2.

Es fa servir "$@" sense cometes de més perquè l'ordre i els seus arguments arribin intactes (03-05), la sortida es descarta per no mesurar el terminal, i la mediana de tres és l'element central de l'array ordenat, que és més robusta que la mitjana davant d'una execució anòmala.

Solució 3. En el primer cas el procés només consumeix 20 segons de CPU dels 310 de rellotge: està esperant, gairebé segur xarxa o disc. Optimitzar el codi no canviarà res; cal buscar l'espera (un curl sense --max-time, un sleep heretat, un ssh sense ControlMaster, una lectura sobre un muntatge de xarxa) i atacar-la amb paral·lelisme, memòria cau o límits de temps. En el segon cas la CPU sí que està ocupada, i el repartiment gairebé a parts iguals entre user i sys delata creació massiva de processos: cal buscar ordres externes dins de bucles i convertir-les en expansions o en un awk d'una passada.

Optimitzar en Bash comença i acaba al mateix lloc: mesurar. time dóna les tres xifres que orienten tota la feina —real és el que pateix l'usuari, user és càlcul i sys és nucli, així que un sys alt significa processos i un real molt superior a user + sys significa espera—; SECONDS acota blocs llargs dins de l'script i date +%s%N blocs curts, sempre repetint la mesura i quedant-se amb la mediana sobre dades representatives. El cost dominant és crear processos: 1-3 ms cadascun, insignificants sols i demolidors multiplicats per mig milió de línies, com demostra el salt de 21 minuts a 12 segons només traient echo i cut de dins del bucle, i d'allà a 0,9 s amb un únic awk. D'aquí se'n deriven les regles pràctiques: fes servir builtins a l'interior dels bucles ($(( )) en comptes d'expr, ${f##*/} en comptes de basename, ${#s} en comptes de wc -c) i no t'hi amoïnis fora; elimina les etapes inútils de les canonades (grep -c en comptes de grep | wc -l, awk que filtra en comptes de grep | awk); llegeix el fitxer una sola vegada calculant tots els agregats en una passada; evita subshells innecessàries, agrupant amb { } en comptes de ( ) i fent servir done < <(cmd); i redirigeix el bucle sencer en lloc d'acumular >>. Entre while read, mapfile i awk, la regla és que si dins del bucle només filtres, comptes o sumes, aquest bucle hauria de ser un awk; mapfile només per a fitxers petits que cal recórrer diverses vegades. Paral·lelitzar amb xargs -P o &/wait és el guany més gran quan la feina és independent i pesada, però no ajuda si el coll d'ampolla és el disc. LC_ALL=C multiplica per quatre la velocitat de sort quan l'ordre byte a byte serveix, i cap registre d'un gigabyte no ha d'entrar en un array. El cas real tanca l'argument: informe-diari.sh va passar de 3 min 12 s a 3,9 s —quaranta-nou vegades— sense tocar la lògica de negoci, i llavors vam parar, perquè optimitzar més un script que corre un cop al dia no li serveix a ningú.

El toolkit ja és llegible i ràpid. Queda la pregunta més incòmoda de les tres que obrien el mòdul: és segur? Aquests scripts executen tasques privilegiades, guarden claus SSH, llegeixen fitxers de configuració amb credencials i processen dades personals de clients. La lliçó 08-03 els audita de dalt a baix: injecció d'ordres i per què eval és una bomba, validació d'entrada amb llista blanca, gestió de secrets, fitxers temporals segurs, mínim privilegi, condicions de cursa i tractament de dades personals, amb una llista de comprovació aplicada al toolkit complet.