epsilon$ while read LINE; do echo \>"$LINE"; done < "Wojciech Jaczewski"
>> Do komórki? Wątpię. Co nie zmienia faktu, że przeciętny twórca programu
>> na komórkę nie będzie się zastanawiał czy zajmie 15, czy 18% czasu
>> procesora.
>Mi nie chodzi nawet o optymalizacje dające 20, czy 30%. Chodzi o to, że
>wielu programistów kierując się zasadą "sprzęt jest tani" ignoruje nawet
>najbardziej oczywiste objawy, pokazujące że tworzony przez nich w taki a nie
>inny sposób program będzie beznadziejnie wolny.

Czy ja gdzieś pisałem, że nigdy nie należy optymalizować? Owszem, jeśli
ktoś wszystko sortuje bąbelkowo, bo inaczej nie umie i nie jest w stanie
zrozumieć, że można inaczej, zapewnie w życiu nie napisze kawałka
dobrego kodu. Tego oczywiście nie neguję. Ale już zastanawianie się nad
kolejnością porównań żeby zyskać kilka procent szybkości przy sortowaniu
kosztem zaciemnienia kodu będzie miało sens tylko w pewnych konkretnych
przypadkach.

>To że często nie opłaca się walczyć o 20% wydajności to się zgadzam.

Ano właśnie.

>Ale już
>o przyspieszenie dziesięciokrotne - warto.

Czasami. Czasami nie. Czasem prościej jest napisać skrypt w bashu, niż
pier.*ić się z C. On i tak będzie uruchamiany raz na rzadko i to, czy
się będzie wykonywać minutę, czy dziesięć nie ma takiego znaczenia, jak
to czy widać co się w nim dzieje.
Co - z drugiej strony - nie zwalnia piszącego taki skrypt od uważania na
to, co robi. (find . -type f -exec cat {} \; anyone?)

>Niby da się przeżyć, że
>użytkownik musi czekać kilka sekund na operację, która bez jakiejś
>nadzwyczajnej optymalizacji mogła by się wykonać w czasie poniżej 100ms.
>Tylko dlaczego robić taki chłam, skoro przy podobnym wysiłku da się to
>zrobić wydajniej.

Owszem. Czasami tak jest. Czasami inny koszt jest po prostu
istotniejszy.

--
[------------------------]
[ K...@e...eu.org ]
[ http://epsilon.eu.org/ ]
[------------------------]