Hejto.pl
Dodaj post

Wpisz coś do wyszukania (minimum 2 znaki)

Wpis użytkownika vrkr w Hydepark

Gruba ryba

w Hydepark

13

Komentarze (5)

Osobistość1

Jak się uczyłem programowania to próbowałem na siłę wszystko utrudnić byle by było najwydajniej. Na szczęście się z tego wyleczyłem. O ile nie piszecie czegoś co będzie działać w tysiącach czy nawet więcej instancji to nie ma większego znaczenia czy wasz program użyje troszkę RAMu więcej. Ale są przypadki gdzie ma znaczenie, ostatnio np. Cloudflare się chwaliło sporą oszczędnością RAMu po zoptymalizowaniu kodu w Rustcie który obsługuje ich DNS 1.1.1.1.

https://ithardware.pl/aktualnosci/cloudflare_100_tb_pamiec_ram_zmiany_kod_rust-53620.html

Cloudflare odzyskało 100 TB pamięci RAM. Wystarczyły zmiany w kodzie RustCloudflare zmniejszyło pamięć wykorzystywaną przez pamięć podręczną DNS w swoim resolverze 1.1.1.1 o ponad połowę, zwalniając około 100 TB pamięci RAM.ITHardware
GURU1

Trzeba wybierać wzgórze, na którym się walczy. Większość można na luzie dwoma tabelami, ale są też miejsca na algorytm, który rzeczywiście robi robotę.

Wiadomo, time to ship jest ważny, ale kurde wydajność kluczowych elementów również

GURU2

@LondoMollari Tak. Działający kod ktory jest nieutrzymywalny jest tak zły jak niedziałający. Robienie wyszukanej architektury jak utrzymywał też będzie potem praktykant przyniesie więcej szkód jak pożytku.

Dosłownie tydzień temu łatałem kod, gdzie architektura była przeliękna i nowoczesna, ale nikomu nie chciało się sprawdzić wydajności na nawet przeciętnym rozmiarze danych :P

Fanatyk4
Wiadomo, time to ship jest ważny, ale kurde wydajność kluczowych elementów również

@Ragnarokk No jasne, wszystko zależy od przypadku, a senior od juniora właśnie różni się tym, że wie w którym przypadku czego użyć. Cackanie się, żeby algo, które realnie pracuje z listą 5-10 elementów, przerobić z O(n^2) na O(n*log n), to zagranie właśnie typowe dla juniorów.

Najistotniejsza moim zdaniem jest prostota koncepcyjna kodu, bo to mocno wpływa na późniejszą rozszerzalność softu, oraz bezpieczeństwo. Przedwczesna optymalizacja z reguły bardziej szkodzi niż pomaga.

Fanatyk10

@vrkr Moim zdaniem inżynier oprogramowania będzie wolał rozwiązanie prostsze koncepcyjnie, którego utrzymanie, debugowanie i rozszerzanie nie będzie wymagało za wiele wysiłku, zamiast super-bleeding-edge rozwiązania, które zaoszczędzi 0.01% cpu i 2% pamięci w ciągu regularnego działania.

Przypomniało mi się, jak na studiach mieliśmy automatyczną testerkę zdań, zadania były pisane jeszcze w Pascalu. Był algorytm + limity pamięci. Algorytm miał działać na liście jednokierunkowej, był skomplikowany i ciężki do debugowania. Ten sam problem był trywialnie prosty do rozwiązania przy użyciu listy powiązanej dwukierunkowo. Oczywiście limity pamięci były dobrane tak, aby struktura danych z dwukierunkowymi wskaźnikami się nie mogła zmieścić... no w każdym razie, autorzy zadania nie wzięli pod uwagę, tego, że ktoś w Pascalu zrobi wstawkę assemblerową, która sobie przerabia wskaźniki kompresując je po drodze (bo było niewiele pamięci do zaadresowania), i w efekcie zmieści listę polinkowaną w obie strony używając skróconych wskaźników. Cóż, byłem wtedy młody i głupi... teraz nie jestem już młody. ( ͡° ͜ʖ ͡°)