final a purystyczne podejście do wydajności

Thread View: pl.comp.lang.java

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Maciek - Wally Fri, 22 Jul 2011 15:48

#152720

Author: Maciek - Wally
Date: Fri, 22 Jul 2011 15:48

21 lines
1957 bytes

Witam,

Zastanawiam się, czy deklarowanie wszystkiego co tylko się da jako final 
ma jakiś sens? Spotkałem się kiedyś ze stwierdzeniem, że znacznie lepiej 
byłoby aby wszystkie zmienne i pola w klasie były domyślnie oznaczane 
jako "final" a dla innych celów powinno istnieć słówko kluczowe 
non-final ;) Oczywiście to dosyć skrajne stwierdzenie, ale zastanawiam 
się czy użycie final w odniesieniu do zmiennej/pola w klasie upraszcza 
czy utrudnia maszynie wirtualnej zarządzanie taką zmienną? Chodzi mi o 
np. zużycie pamięci czy też samą złożoność obliczeniową, a nie o 
znaczenie tego słówka kluczowego - do czego służy, wiem. Zastanawiam się 
czy warto je stosować nie tylko wtedy, kiedy jest to niezbędnie 
konieczne, ale może również wszędzie tam gdzie jest to po prostu 
możliwe. Wiem że druga opcja pomoże wykryć wiele błędów projektowych już 
w momencie kompilacji, ale mi chodzi o purystyczne podejście do 
wydajności ;)

Co o tym sądzicie?

-- 
Maciek

Re: final a purystyczne podejście do wydajności

#152721

Author: Marcin Mielżyński
Date: Fri, 22 Jul 2011 22:02

37 lines
2445 bytes

W dniu 2011-07-22 17:48, Maciek - Wally pisze:
> Witam,
>
> Zastanawiam się, czy deklarowanie wszystkiego co tylko się da jako final
> ma jakiś sens? Spotkałem się kiedyś ze stwierdzeniem, że znacznie lepiej

wrt wydajności:

Pola statyczne final - javac robi constant folding, więc nie ma potem 
ich kosztu w runtime (np: static final boolean foo; i branche dla niego 
zostaną wyeliminowane).

Klasy/metody final - nie ma znaczenia w wydajności, dzisiejsze maszyny 
dewirtualizują pojedyncze implementacje metod przy analizie hierarchii, 
także mogą one być w pełni inlinowane pomimo że nie są final (plus 
zaniedbywalny koszt strażnika deoptymalizującego).

Zmienne lokalne final - nie ma znaczenia w wydajności, na grafie SSA i 
tak wychodzi czy nazwa jest użyta tylko raz.

Pola instancji final - nie ma znaczenia, maszyny nie robią alias 
analysis dla pól.
(generalnie pola instancji final mogą nieco pogorszyć wydajność alokacji 
ponieważ w takim przypadku jvm musi utworzyć barierę zapisu przy ich 
konstrukcji - jsr-133)

wrt bezpieczeństwa kodu - warto tylko dawać tam gdzie istnieje realna 
szansa na popełnienie nielokalnej pomyłki (a więc głównie pola, czasem 
blokowanie zasłaniania metod). Markowanie finalami wszystkich parametrów 
metod i zmiennych drastycznie zmniejsza czytelność kodu nie dając wiele 
w zamian.

Jeżeli bardzo zależy na bezpieczeństwie (type safety/state control) to 
najlepiej zmienić język.


lopex

Re: final a purystyczne podejście do wydajności

#152722

Author: clyde
Date: Mon, 25 Jul 2011 21:16

46 lines
2876 bytes

Kwestia wydajnosci final/non final to zadna kwestia.

Ale co do 'bezpieczenstwa' osobiscie bardzo cenie sobie oznaczanie jako 
final zmiennych instancji obiektu, ktore wtedy musza byc zainicjowane w 
konstruktorze lub przy deklaracji.


W dniu 2011-07-23 00:02, Marcin Mielżyński pisze:
> W dniu 2011-07-22 17:48, Maciek - Wally pisze:
>> Witam,
>>
>> Zastanawiam się, czy deklarowanie wszystkiego co tylko się da jako final
>> ma jakiś sens? Spotkałem się kiedyś ze stwierdzeniem, że znacznie lepiej
>
> wrt wydajności:
>
> Pola statyczne final - javac robi constant folding, więc nie ma potem
> ich kosztu w runtime (np: static final boolean foo; i branche dla niego
> zostaną wyeliminowane).
>
> Klasy/metody final - nie ma znaczenia w wydajności, dzisiejsze maszyny
> dewirtualizują pojedyncze implementacje metod przy analizie hierarchii,
> także mogą one być w pełni inlinowane pomimo że nie są final (plus
> zaniedbywalny koszt strażnika deoptymalizującego).
>
> Zmienne lokalne final - nie ma znaczenia w wydajności, na grafie SSA i
> tak wychodzi czy nazwa jest użyta tylko raz.
>
> Pola instancji final - nie ma znaczenia, maszyny nie robią alias
> analysis dla pól.
> (generalnie pola instancji final mogą nieco pogorszyć wydajność alokacji
> ponieważ w takim przypadku jvm musi utworzyć barierę zapisu przy ich
> konstrukcji - jsr-133)
>
> wrt bezpieczeństwa kodu - warto tylko dawać tam gdzie istnieje realna
> szansa na popełnienie nielokalnej pomyłki (a więc głównie pola, czasem
> blokowanie zasłaniania metod). Markowanie finalami wszystkich parametrów
> metod i zmiennych drastycznie zmniejsza czytelność kodu nie dając wiele
> w zamian.
>
> Jeżeli bardzo zależy na bezpieczeństwie (type safety/state control) to
> najlepiej zmienić język.
>
>
> lopex
>

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads