Da har jeg laget en ny optimalisering av scriptet, nemlig parallellisering for å utnytte multi-CPUer bedre.
Siden scriptet baserer seg på å pipe output fra SoX direkte inn i Lame så er det slik at scriptet allerede var parallellisert noe i form av at lame encodingen og flac-dekodingen/sox-prosesseringen skjedde i ulike prosesser og dermed ble parallellisert. Men nå har jeg skrevet om scriptet slik at hele reenkodingsprosessen, både deteksjon av endrede filer, reenkoding og tagging, skjer i parallell med et egendefinert antall samtidige prosesser. Siden dekoding/enkoding allerede er parallellisert bør man ikke velge alle CPUer, men N-1 fungerer fantastisk her med min quad core, dvs 3 samtidige prosesser.
I tillegg har jeg parallellisert replaygain delen, slik at også dette kan fungere på samme måte. Dette gjøres imidlertid på per directory basis for å kunne benytte replaygain_album_* logikken i mp3gain direkte. Det vil si at man f.eks replaygainer 3 directories i parallell.
Som en konsekvens av all parallelliseringen er nå output fra alle underprosesser fjernet, og kun en enkel (fargelagt) statusmelding printes til skjerm for hver fil som prosesseres. Alt annet blir tilfeldig kaos.
Alt i alt er scriptet nå lynraskt, både på sjekk av eksisterende filer som ikke trenger å endres (siden dette også skjer i parallell), og på alle de tunge prosessene.
Jeg skal imidlertid teste det noe mer før jeg frigir den nye varianten, men jeg ser ingen problemer sålangt.