🚀 go-pugleaf

> Dla mnie szczególnie cenne jest to, że teraz na wejściu i wyjściu z metody
> nie będą wszystkie zmienne z typami zarządzalnymi (jak string, rekordy,
> tablice czy interfejsy) alokowane i zwalniane, lecz tylko wtedy, gdy
> wykonanie kodu wejdzie w blok, np. po staremu:
>
> function Test(wartosc : integer) : Integer;
> var
>  WielkaTablica : array[milion] of Integer;
> begin
>  if wartosc > 10 then
>  begin
>   result := WielkaTablica[wartosc];
>  end;
> end;

Piszesz o typach zarządzalnych, a podajesz, jako przykład deklarację lokalnej tablicy
o stałym rozmiarze alokowaną na stosie. Nikt, o zdrowych zmysłach, nie zadeklaruje
tablicy o takim rozmiarze na stosie, a jakby się taki znalazł, to dostanie na wejściu do
tej funkcji "stack overflow".

> Wywołanie powyższej metody powoduje, że na początku tablica jest alokowana
> (4 MIB ramu!), a na końcu zwalniana, nawet jeśli jej nie tkniemy! Tak teraz
> to działa, można zobaczyć w oknie ASM debugera.
>
> Teraz, po nowemu gdy będzie tak:

> function Test(wartosc : integer) : Integer;
> begin
>  if wartosc > 10 then
>  begin
>   var WielkaTablica : array[milion] of Integer;
>   result := WielkaTablica[wartosc];
>  end;
> end;

> To tylko jeśli wartosc wejściowa spełni warunek i wykonanie wejdzie w
> begin/end warunku to nastąpi alokacja i zwolnienie, w innych przypadkach
> nie tknie pamięci!

W tym przypadku nic się nie zmieni, jeśli chodzi o miejsce i moment alokacji
pamięci dla tej konkretnej tablicy - nadal będzie rezerwowana na stosie
w momencie wejścia do funkcji Test. Ale żeby była jasność - ta tablica nie jest
zmienną zarządzalną. Podając przykład z tą tablicą tylko namieszałeś ludziom
w głowach.

> I teraz przełóżmy to na 10 zmiennych lokalnych, to nawet mogą być puste
> stringi, nastąpi ich alokacja i zwolnienie. I teraz tak w każdej
> metodzie... czujesz olbrzymią wydajnościową różnicę? Ja tak.

Wydajnościowo, to czasem może być nawet gorsze od deklarowania wszystkich
zmiennych na początku procedury/funkcji, jeśli ktoś nie wie, gdzie i kiedy są
alokowane zmienne zadeklarowane w lokalnych blokach begin end i jak często
są inicjalizowane i finalizowane (np. w pętli).

Jeśli w takim bloku begin end zadeklarujemy choć jedną zmienną zarządzalną,
to automatycznie zostanie utworzona kolejna ramka stosu, a to kosztuje
tyle samo, co utworzenie kolejnego bloku try finally end, tylko niejawnego.

Natomiast zysk wydajnościowy z używania "inlined variables" (nie wiem,
jak to przetłumaczyć na polski) jest niewielki i dotyczy jedynie prostych
operacji, których czasem może nie być, czyli ustawienia wskaźnika na nil
podczas inicjalizacji zmiennej zarządzalnej oraz sprawdzenia, czy wskaźnik
nie jest nil, przy jej finalizacji.

Zmienia się natomiast moment inicjalizacji i finalizacji tych zmiennych,
ale nic się nie zmienia, jeśli chodzi o alokację zmiennych - pamięć dla
przechowania np. nowego stringa jest nadal alokowana na stercie
w momencie przypisania wartości do zmiennej lub użycia SetLength.
Na stosie jest jedynie ustawiany wskaźnik, który pokazuje na zawartość
tego stringa utworzonego na stercie.

Taki sam lub nawet lepszy efekt wydajnościowy uzyskamy w każdej wersji
Delphi wydzielając z dużej procedury/funkcji mniejsze podprocedury, które
będą wywoływane 1 raz lub wcale, ale będą miały własne deklaracje tylko
swoich zmiennych lokalnych. No ale to przecież jest strasznie czasochłonne
dla dzisiejszych programistów ;-)

-- 
pozdrowienia
Krzysztof Szyszka, X-Files Software
Developer of X-DBGrid Component
Embarcadero Technology Partner
http://www.x-files.pl/