Fa uns dies vaig deixar algunes recomanacions sobre programació. En el mateix temps cronològic que vaig aprendre allò també vaig aprendre algunes coses d’optimització que deixo aquí.
Si és possible, “benchmarka”. Fer que funcioni i llavors optimitzar. No optimitzar el codi que no funciona
Segurament és fruit de la (mala) experiència d’aquest cop. Vaig mig fer una feina i havia d’anar MOLT més ràpid. Quan dic molt vull dir 10 o 100 vegades més ràpid. Em va passar dos cops: vaig fer una mitja implementació, lenta. Vaig optimitzar-la força. Un cop tenia la mitja-implementació optimitzada, resulta que l’enfoc de l’implementació no era correcte i no podia funcionar mai al 100% (o molt difícilment). En el meu cas, segurament hagués estat millor fer que funcionés i llavors optimitzar. A més a més, acabar d’afegir funcionalitat a un codi massa optimitzat pot ser dur (especialment si no es fa cas de la següent idea).Quan ho feia no veia manera de fer un benchmark per saber si podia ser suficientment ràpid, per això ho optimitzava sense ser funcional. En el meu cas no ho havia planificat massa bé, aquest tema.
Separar part funcional i optimització. Fer les optimitzacions fàcils de desactivar (serà més fàcil de testejar)
Una optimització molt bona que em va sortir és una variable que guarda un valor calculat, que és vàlid si no passen certs events. Durant algunes proves, quan no funcionava bé quelcom, desactivava la part del caché. Si seguia sense anar bé ja sabia que no era cosa de les optimitzacions. Almenys dona confiança amb el codi. Tothom s’equivoca programant.
No confiançar amb cap mètode que no sigui nostre. Benchmark!
En algunes parts feia servir mètodes de llibreries que no he implementat jo. Em vaig trobar amb varis mètodes que, en funció de la mida del problema, tardaven molt més quan el temps hagués hagut de ser constant.La solució és fàcil: guardar-me el valor de nou i no cridar el mètode cada cop. Però impressionant com qualsevol tonteria canviava en funció del problema, tot i que no hauria de ser així. Fent uns benchmarks vaig veure com fugia el temps per llocs inesperats.
Caché de variables: fer condicions de validesa/invalidesa que siguin econòmiques de verificar
Evidentment, depen del problema. En el meu cas, com que la funció es pot calcular força ràpid, és més senzill invalidar el valor cachejat freqüentment i calcular de nou que no haver de pensar molt si s’invalida el valor cachejat (ja que amb aquest temps el puc tornar a tenir 🙂 )Si tenim una funció que s’executa sovint al programa i ens gasta massa temps tenim varies opcions: o que s’executi més ràpid o bé no executar-la tant (cachejant valors, etc.). O bé canviant totalment l’algorisme, estructures de dades, etc.
Apèndix de vocabulari
No sé cap traducció bona de benchmark. El més semblant és “prova de velocitat”, “mesura de velocitat” o semblant. No hi he sabut trobar però una paraula bona. El mateix amb “cache”, sé que se sol utilitzar “memòria cau” per “memòria caché” però no em serveix per “cachejat” (guardat a la memòria cau?). A més m’adono que per acabar-ho d’adobar he mig catalanitzat la paraula… hi pensaré.
Leave a Reply