@Varin: W aplikacjach typu crud / mikroserwisy które pisze większość programistów to jest małoważne, bo większość czasu programy spędzają czekając na I/O niż korzystając z CPU.
@scriptkitty: Tak, w API czy czymkolwiek związanym z DB to requesty i DB będą bottleneckiem. Jednak ostatnio pisałem prawie roczny projekt importu danych z jednego systemu do drugiego, gdzie dane trzeba bylo wyciagnac, przekonwertowac i zapisac w nowej DB. Duzo operacji na CPU, miałem nawet ustawienie gdzie program dzielił wszystkie operacji na tyle wątków ile miał procesor, i równorzędnie na wątkach te procesy cisnął, potem zapisując resultaty do "thread safe" kolekcji...
@Saly: Zgadza się, ale to wciąż mikrooptymalizacja. Według mnie powinno się na takie rzeczy zwracać uwagę dopiero gdy okazuje się, że program jest za wolny - przy pomocy profilera. Bo intuicja bardzo często podpowiada nam złe miejsca.
Oczywiście jeśli piszesz grę, albo sterownik albo coś innego co z założenia ma mieć dużą wydajność to wtedy ma sens przyglądać się takim szczegółom.
projekt importu danych z jednego systemu do drugiego, gdzie dane trzeba bylo wyciagnac, przekonwertowac i zapisac w nowej DB
@Varin: no i będziesz to odpalać codziennie przez rok czy raz i koniec? Zgaduję, że nie ma to żadnego znaczenia ile to będzie trwało, bo choćby miało tydzień chodzić to jest to jednorazowa akcja i dobranoc. Ważniejsze jest, żeby tam bugów nie było przez małoczytelny kod i jakieś gimnastyki z arrayami byle
@Varin: każdy Unity developer takie rzeczy ogarnia i to że foreach kiedyś alokował pamięć na heap na obiekt do enumeracji. Jak masz 16ms na ogarniecie wszystkiego w tym iterowanie po tysiącach elementów to takie rzeczy ma sie w małym palcu. Każdy programista z gamedev zna tez inne znaczenie DDD czyli Data-driven design czyli układanie danych w pamięci tak żeby korzystać z cachingu w CPU i operacji SIMD. Pomaga w tym Entity
@zibizz1: Ciekawa sprawa, ale chyba jest tak jak wielu tutaj mówi. Time To Market to zmora programistów perfekcjonistów, bo w większości biznesów to się liczy, w apkach biznesowych takie oszczędności mało znaczą bo mamy ciągłe requesty do API albo bazy danych co zajmuje o rząd większości ... więcej... czasu a tego się zredukować łatwo nie da, a na pewno nie do poziomu gdzie operacje na tablicach mają znaczenie.
@Varin: Najczęściej nie opłaca się optymalizować przez Premature Optimization. Łatwiej wydać 10k USD więcej za sprzęt i zasoby (albo zmusić użytkowników do zakupu lepszego sprzętu) niż zapłacić programistom za dłubanie i zaciemnianie kodu poprzez pisanie szybszego kodu. Firmom nie przeszkadza płacenie miliona za chmure miesięcznie dopóki ma kilka milionów przychodu, dopiero gdy linie na wykresie zaczynają się przecinać ktoś zaczyna analizować i okazuje się że da się utrzymać infrastrukturę za 50k
@Varin: for vs foreach też zależy co się faktycznie w tej pętli w środku dzieje. Bo jeśli odpytujemy tablicę raz, to tak, foreach będzie wolniejszy, jeśli odpytujemy tablicę np. kilka razy, to for już może być wolniejszy.
A i tak głównie się rozchodzi o czytelność, a tutaj foreach wygrywa prawie zawsze. Często też używam LINQ, bo kod wtedy się sam dokumentuje.
@Varin: jak trzeba zmieniać wartości i w iterowanej kolekcji. Inaczej to foreach. Optymalizacja w gównoapkach, które klepie 80% programistów nie ma sensu. Więcej Ci zajmie rozkminianie tego niż jest faktyczny zysk. Tak jak ktoś pisał: optymalizacja profilerem jak się okazuje, że produkcja nie ogarnia takich requestów.
forw C# ?#programista25k #programista15k #programowanie
Oczywiście jeśli piszesz grę, albo sterownik albo coś innego co z założenia ma mieć dużą wydajność to wtedy ma sens przyglądać się takim szczegółom.
Zgaduje że przez 14 lat zdołali naprawić kompilatory
Aktualnie w 90% przypadków ważniejszy jest TTM i czytelność kodu. A takie optymalizacje nie dają żadnego widocznego zysku.
@Varin: no i będziesz to odpalać codziennie przez rok czy raz i koniec? Zgaduję, że nie ma to żadnego znaczenia ile to będzie trwało, bo choćby miało tydzień chodzić to jest to jednorazowa akcja i dobranoc. Ważniejsze jest, żeby tam bugów nie było przez małoczytelny kod i jakieś gimnastyki z arrayami byle
jezeli uzywasz skrotow, ktorych nie da rady wygooglowac to znaczy, ze jestes debilem
aha, ok
W gamedevie inna
A i tak głównie się rozchodzi o czytelność, a tutaj foreach wygrywa prawie zawsze. Często też używam LINQ, bo kod wtedy się sam dokumentuje.