🚀 go-pugleaf

On Tue, 30 Oct 2018 20:35:22 +0100, Krzysztof Szyszka wrote:

>> 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".

Masz rację co do niepraktyczności przykładu, po prostu chodziło mi o jasny
przekaz i na kolanie to napisałem, ale przyjąłem niepoprawny typ tej
tablicy, gdyby był of string to byłoby to o co chodzi. Lub rekord czy
tablica rekordów.

>> 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.

Zmieni się ten aspekt właśnie, alokacja będzie w chwili użycia a nie po
wejściu do procki. I to jest olbrzymia różnica, która mnie cieszy.

>> 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).

Niewiedza zawsze będzie przyczyną problemów, ale nie o tym mowa, nie na tym
się skupiajmy.

> 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.

Moje odczucia okazuje się nie są całkiem samotne:

https://blog.grijjy.com/2018/11/02/inline-variables-can-increase-performance/

-- 
pozdrawiam
Roman Tyczka