Cześć. A Wy co preferujecie gdy piszecie soft? Robicie trochę mniej wydajne rozwiązanie ale macie pewność że będzie dobrze działało, czy robicie bardzo wydajne rozwiązanie ale ryzyko błędu jest większe (w końcu zawsze są jakieś wyjątki od reguły)?
0
1
Nie widzę związku wydajności z błędogennością.
Ja preferuje czytelność rozwiązania i testowalność. Bo jak kod jest elegancko napisany to nawet jak coś w nim nie działa, to można to łatwo poprawić.
0
jak dla mnie to też pytanie z tyłka - co ma jedno do drugiego???
0
Ja widzę. Np. w grach często pojawiają sie błędy wyświetlania, niedokładne wykrywanie kolizji itp. co mnie nie dziwi bo gry się robi pod to, żeby szybko działały przede wszystkim nawet kosztem poprawności.
Z drugiej strony systemów bankowych chyba nikt tak nie robi (mam nadzieję).
I tu należy sie zastanowić o jakiego rodzaju programach piszemy.
Poza tym - to że w grach występuje czesto poswiecanie poprawnosci na rzecz wydajnosci, nie znaczy to, że to ma być regula w innych rodzajach softu. Można napisac przeciez w wielu przypadkach coś, co bedzie szybko dzialalo oraz bylo poprawne,..
0
no tak. ale gdy nie jesteśmy w stanie dać 100% gwarancji że nasze bardzo wydajne rozwiązanie będzie działać tak jak w przypadku mniej wydajnego rozwiązania (głównie zawsze różni się to przecież stopniem skomplikowania) a samo rozwiązanie ma DZIAŁAĆ a nie sypać się to co wtedy? np jeśli takie coś miałoby wyjść w release?
2
A skąd gwarancja, że to mniej wydajne rozwiązanie nie będzie się sypać?
Częściej spotykałem się z sytuacjami, że słaby programista pisze trudny w utrzymaniu, trudny w weryfikacji i powolny kod, a dobry programista pisze czytelny, łatwy w weryfikacji i zarazem szybki (na dodatek w 1/3 czasu), niż z sytuacją, że kod stał się nieczytelny lub wręcz błędny przez nadmierną optymalizację.
Wielokrotnie też zdarzało mi się poprawiać własny kod w taki sposób, że po poprawkach był równocześnie i prostszy, i szybszy.
Oczywiście istnieje pewna klasa tricków, które pozwalają uzyskać większą szybkość kosztem np. gorszej dokładności, choć niekoniecznie skomplikowania kodu. Przykładem mogą być różne heurystyki rozwiązujące problemy NP-trudne. Algorytm dokładny jest zwykle znacznie trudniej napisać niż np. heurystykę zachłanną dającą przybliżone wyniki. W wielu sytuacjach nie potrzeba dokładnych wyników, więc heurystyki są stosowane bardzo powszechnie. Ale nie traktuję ich jako rozwiązania "niepoprawnego", a raczej pewien kompromis.
2
Wielokrotnie też zdarzało mi się poprawiać własny kod w taki sposób, że po poprawkach był równocześnie i prostszy, i szybszy.
Najlepszy typ commitów.
"tcp/dccp: lockless listener"
"307 insertions(+), 746 deletions(-)"
"about 2 to 3 order of magnitude what we had with older kernels"
0
Pytanie newbiego.
Naprawdę, nie zdarza się, że aby wyżyłować wydajność, robi się tak brzydkie rzeczy jak ręczne rozwijanie pętli, byleby tylko wywalczyć kilka ifów mniej?