Roller, generalnie każde idę jb to po prostu bundle idei z rozszerzeniami
Wersja do druku
Roller, generalnie każde idę jb to po prostu bundle idei z rozszerzeniami
Yea, i to nie jest problem. Problemem byłoby to gdyby każde IDE było probione po łebkach i na 'jedno kopyto' byle było. A tak nie jest.Cytuj:
zakius napisał
jedyny minus ide od jb to 350 mb ramu zajęte zaraz po odpaleniu, po kilkudziesięciu minutach pracy lekkim chujem pół gigabajta
dla porównania vs zaraz po uruchomieniu i odpaleniu jednego projektu zajmuje ~130 mb
Od kiedy to vs nie zjada calydostepny*1.1?
przynajmniej od 2013
Ogromny problem w dzisiejszych czasach, gdzie 8GB RAMu to standard.Cytuj:
2cztery7 napisał
taa, developetrzy mają w dupie optymalizacje, a potem robią gry wymagające 16 gb ramu i dwóch kart graficznych z najwyższej półki i chłodzenia ciekłym azotem xD
Mają w dupie bo raz, że nie mają pojęcia o komputerach bo przecież studia nie są potrzebne, a dwa, biznes ciśnie i nie ma czasu na optymalizację bądź korzystanie z języka z ręcznie zarządzaną pamięcią. Realne życie to nie akademicka walka o każdy bajt pamięci.Cytuj:
2cztery7 napisał
Dobre gada, polać muCytuj:
Wielkie Zło napisał
ale nie można przesadzać też w druga stronę, czyż nie?Cytuj:
Wielkie Zło napisał
Odnośnie optymalizacji kodu, ostatnio czytając ksiazke A. Williams'a (C++ Concurrency in Action, polecam) podał on fajny przykład odnosnie aplikacji single i multithreaded. Kiedyś kiedy wszyskie (większość domowych komputerów) miała 1 rdzeń, programisci pisali aplikacje na 1 rdzen - i w miare czasu, jak producenci procesorów wprowadzali lepsze procesory, ich aplikacje samoczynnie stawały się szybsze. Sytuacja się zmieniła, gdy producenci procesorów zaczli wprowadzać procesory multirdzeniowe na dekstopowe PC - wtedy programisci musieli zmienić swoje aplikacji (w większości case je przepisać), żeby supportować tą większą moc obliczeniową. Oczywiście część programistów pojechała po bandzie, i przesiadła się na języki/technologie które robią to ^ za nich.Cytuj:
Wielkie Zło napisał
Z drugiej strony, stoi PM/PO ktory średnio dba o to czy Twoj kod jest schludny/szybki/whatever, dla niego ważniejsze są zrobione ficzerki ze sprinta - implikuje to też presję na programiscie.
Z trzeciej strony, w myśl pojecia "Profesjonalista" jakim posluguje sie wujek Bob - programista ma uświadamiać swojego pracodawcę, że są rzeczy których nie można przyspieszyć kosztem jakości. Bo z każdą taką presją problemy się piętrzą, a ostatecznie to jest wina programistów że program działa gorzej niż mógłby. Ale standardowo wszystko kończy się na "To zależy..." :D A naprawianie "po" jest ZAWSZE drozsze niz "teraz".Cytuj:
szulak napisał
Moim zdaniem nie istnieje coś takiego jak "przesadzenie z optymalizacją". Jest kod mniej lub bardziej zoptymalizowany. Fakt, często im bardziej odptymalny tym mniej czytelny, ale... Od tego są komentarze ;)Cytuj:
zakius napisał
Przy okazji rozmow o optymalizacji warto wspomniec o YAGNI
Cytuj:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%
Yeah, ale realia są troszkę inne. Jak masz grooming/planning, to oceniasz task na powiedzmy 3 dni. Po 3 dniach, okazuje się że było 10 problemów więcej do rozwiązania, więc sprint i demo jest zagrożone - więc się nadrabia.Cytuj:
Bazan napisał