Czy w Javie jak jakaś metoda jest często wywoływana to powinna zawierać lokalne zmienne? Czy lepiej aby miała zmienne zdefiniowane po prostu w klasie i je wykorzystywać w metodzie? Kiedyś pamiętam że gdzieś czytałem że lepiej by w metodzie którą często się używa lepiej aby nie było inicjalizacji zmiennych bo wtedy program będzie musiał je na nowo tworzyć i usuwać, ale raz to chyba nie było odnośnie Javy, dwa to było z 14 lat temu to się zmienić mogło. Kompilator mi podpowiada aby właśnie definiować zmienne bezpośrednio w metodzie ale nie wiem czy mu wierzyć. ( ͡°͜ʖ͡°)
W sensie ja wiem że mogą być różne przypadki jak np wielowątkowość, czy zajmowanie pamięci itd, ale mi chodzi po prostu o najprostszy program który powiedzmy wywołuje w kółko jakaś metodę i hiperbolizując - niech ta metoda ma z 20 tysięcy zmiennych, lepiej aby je zdefiniować lokalnie w metodzie czy w klasie?
co jest znacznie cenniejsze niż czas procesora -> czyli czasu programisty.
@MacDada: Jest to bardzo duże uproszczenie, do tego stopnia, że jest bezużyteczne (i w ogólności tzw. gównoprawda), bo jest wiele innych zmiennych wpływających na rachunek kosztów. Wprawdzie czas pojedynczego procesora może i jest tańszy od czasu programisty w bezpośrednim porównaniu, ale:
1. zadanie może być bardzo duże i ktoś zwyczajnie tego czasu może nie mieć - kupiłbyś program do obróbki zdjęć, który jedno zdjęcie obrabiałby przez 3 dni? 2. zadanie musi być rozwiązane w konkretnym czasie i jak się spóźni nawet o sekundę, to oznacza że nie zostało rozwiązane wcale (np. kogoś
A moja teza jest: nie ma znaczenia. Nie tutaj będziesz miał bottleneck wydajnościowy.
@MacDada: tak jak pisałem wyżej, to akurat mocno zależy. Sama zmienna kosztuje tyle co nic, ale mówimy o javie, więc jakikakolwiek nietrywialna wartość wymaga obiektu na stercie i zmiennej trzymającej referencję do tego obiektu. I tutaj jak najbardziej alokacja dużej liczby obiektów na stercie może spowolnić program nawet 100x i będzie to o tyle wredne, że akurat
@Krolik: oczywiście, że uproszczenie, bo nie będę przecież smarował elaboratu na 100 stron, przelewające całe moje doświadczenie i świadome mi kompromisy programistyczne z różnych perspektyw, bo ktoś zadał pytanie na mirko :P
na tym polegają "reguły" czy też "zasady", że oczywiście są od nich wyjątki.
i co do zasady jestem mocnym zwolennikiem szeroko rozumianego procesu o nazwie make it work, make it right, make it fast [enough] – a w
make it work, make it right, make it fast [enough]
@MacDada: czyli odwrócony waterfall - w klasycznym waterfallu najpierw zbierasz wymagania, potem projektujesz, na końcu robisz. Ty widzę najpierw robisz, potem projektujesz, a na końcu patrzysz na wymagania i próbujesz je spełnić. Seems legit. Może do jakichś CRUDów tak można, ale w każdym nietrywialnym projekcie, w którym widziałem to podejście, kończyło się to spektakularnym g***nem, które ani nie miało dobrej
Kompilator mi podpowiada aby właśnie definiować zmienne bezpośrednio w metodzie ale nie wiem czy mu wierzyć. ( ͡° ͜ʖ ͡°)
W sensie ja wiem że mogą być różne przypadki jak np wielowątkowość, czy zajmowanie pamięci itd, ale mi chodzi po prostu o najprostszy program który powiedzmy wywołuje w kółko jakaś metodę i hiperbolizując - niech ta metoda ma z 20 tysięcy zmiennych, lepiej aby je zdefiniować lokalnie w metodzie czy w klasie?
#java #programowanie #pytanie #kiciochpyta
@Sinti: przez 3 miechy pracy nauczyłem się więcej niż przez 3 lata studiów
@MacDada: Jest to bardzo duże uproszczenie, do tego stopnia, że jest bezużyteczne (i w ogólności tzw. gównoprawda), bo jest wiele innych zmiennych wpływających na rachunek kosztów. Wprawdzie czas pojedynczego procesora może i jest tańszy od czasu programisty w bezpośrednim porównaniu, ale:
1. zadanie może być bardzo duże i ktoś zwyczajnie tego czasu może nie mieć - kupiłbyś program do obróbki zdjęć, który jedno zdjęcie obrabiałby przez 3 dni?
2. zadanie musi być rozwiązane w konkretnym czasie i jak się spóźni nawet o sekundę, to oznacza że nie zostało rozwiązane wcale (np. kogoś
@MacDada: tak jak pisałem wyżej, to akurat mocno zależy. Sama zmienna kosztuje tyle co nic, ale mówimy o javie, więc jakikakolwiek nietrywialna wartość wymaga obiektu na stercie i zmiennej trzymającej referencję do tego obiektu. I tutaj jak najbardziej alokacja dużej liczby obiektów na stercie może spowolnić program nawet 100x i będzie to o tyle wredne, że akurat
na tym polegają "reguły" czy też "zasady", że oczywiście są od nich wyjątki.
i co do zasady jestem mocnym zwolennikiem szeroko rozumianego procesu o nazwie make it work, make it right, make it fast [enough] – a w
@MacDada: czyli odwrócony waterfall - w klasycznym waterfallu najpierw zbierasz wymagania, potem projektujesz, na końcu robisz. Ty widzę najpierw robisz, potem projektujesz, a na końcu patrzysz na wymagania i próbujesz je spełnić. Seems legit. Może do jakichś CRUDów tak można, ale w każdym nietrywialnym projekcie, w którym widziałem to podejście, kończyło się to spektakularnym g***nem, które ani nie miało dobrej