Administrace komentářů

mam totiz takove divne mrazeni, ze to bude pomale

Takze je to pomale, alebo nie? Ak je vykonnost dostatocna, riesis neexistujuci problem. Prepisovat 50 riadkov zdrojoveho kodu (t.j. excelentne strucne riesenie) do 500 riadkov potencialne rychlejsieho C kodu bez realneho dovodu je dobre iba ak z akademickych dovodov. Treba si uvedomit, ze N-nasobok poctu riadkov zdrojoveho kodu zo sebou nesie N-nasobne riziko chyby v kode. Nepozeral som co vlastne ten skript robi, ale v zasade vidim dve mozne priciny "pomalosti":

1) IO operacie. V tomto pripade je rychlost vykonavania samotnej riadiacej rutiny, t.j. post-commit hooku irelevantna, a zrychlit treba IO operacie samotne.

2) Neefektivny algoritmus riadiacej rutiny, napr. viacnasobne ziskavanie nejakej informacie ci suboru. V tomto pripade treba vylepsit algoritmus, napr. vyhnut sa opatovnemu ziskavaniu udajov. V tomto pripade opat nezalezi na implementujucom jazyku; opat vitazi program s jednoduchsim (kratsim) zapisom.

Jedna moznost, kedy by mohol byt shellovy skript na tom zle, je spustanie velkeho poctu procesov; napr. ked bude pre kazdy z tych 11k suborov spustat nejaky externy program, aby ho spracoval. V tomto pripade ale s vysokou pravdepodobnostou pojde problem riesit davkovym spracovanim, t.j. v zasade spustenim externeho programu naraz pre viacero suborov; vacsina unixovych toolov toto umoznuje, find a xargs su dobri pomocnici.

Nakoniec -- alebo skor na zaciatok -- aky "biznis" problem vlastne riesis? Existuje viacero hotovych rieseni na publikovanie SVN repozitarov cez web. I ked na druhej strane, Tvoj problem moze byt unikatny a teda moze vyzadovat unikatne riesenie. Sam som pomocou post-commit hookov naprogramoval v shelli uz dve continuous integration riesenia; a boli to stovky az tisice riadkov shellovych skriptov.