W obj-c jest cos co nazywa sie 'autorelease pools' i o ile rozumiem
jest to posredni stopien miedzy recznym zarzadzaniem pamiecia
(przez free/delete/release itp) a grabage collectorem.

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
//tu wywolaj funkcje
[pool release];

Dziala to tak ze wybrane (tj te obslugujace autorelelease) obiekty tworzone
po zalaczeniu poola sa rejestrowane i nie trzeba ich zwalniac - zostana usuniete
przy niszczeniu (albo drainowaniu) poola.

Sam nie za bardzo znam sie ani na kwestiach dotyczacych gc ani tez i recznej
gospodarki pamiecia ale pamietam ze toczyly sie tu onegdaj dyskusje nt jednego i
drugiego a chyba nie byl omawiany wlasnie ten posredni przypadek ([sam jestem
raczej zwolennikiem w wiekszosci statycznego podejscia - czyli mozna by to nazwac
jeszcze 'czwarta droga'); jakby co to chetnie uslysze zdania dotyczace tego
'posredniego'
miedzy gc a reczna gosp sposobu.




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-09-13 13:27, kenobi pisze:
> W obj-c jest cos co nazywa sie 'autorelease pools' i o ile rozumiem
> jest to posredni stopien miedzy recznym zarzadzaniem pamiecia
> (przez free/delete/release itp) a grabage collectorem.
>
> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
> //tu wywolaj funkcje
> [pool release];
>
> Dziala to tak ze wybrane (tj te obslugujace autorelelease) obiekty tworzone
> po zalaczeniu poola sa rejestrowane i nie trzeba ich zwalniac - zostana usuniete
> przy niszczeniu (albo drainowaniu) poola.
>
> Sam nie za bardzo znam sie ani na kwestiach dotyczacych gc ani tez i recznej
> gospodarki pamiecia ale pamietam ze toczyly sie tu onegdaj dyskusje nt jednego i
> drugiego a chyba nie byl omawiany wlasnie ten posredni przypadek ([sam jestem
> raczej zwolennikiem w wiekszosci statycznego podejscia - czyli mozna by to nazwac
> jeszcze 'czwarta droga'); jakby co to chetnie uslysze zdania dotyczace tego
'posredniego'
> miedzy gc a reczna gosp sposobu.

Świetnie się stosuje np. w przypadku, gdy w ramach jakiegoś
separowanego przetwarzania musisz tworzyć dużo małych obiektów
tymczasowych, a co najwyżej niektóre z nich będą potrzebne jako wyniki.
(Ewentualny koszt kopiowania z puli do "innej" pamięci jest mały)

Wtedy zysk jest duży:
- alokacja z puli może być bardzo szybka (szczególnie, gdy dostęp do
niej jest z jednego wątku, a obiekty są zbliżonych rozmiarów)
- dealokacja puli jest jeszcze szybsza 8-)
- na pewno wszystkie obiekty z puli zostaną usunięte - nie można mieć
wycieków pamięci, o ile tylko zwolni się pulę (i nie ma referencji
z obieków z puli, ale tym powinny zająć się ewentualne destruktory).
Do tego zarządzanie jest bardzo proste - tworzę, tworzę,... potem
niszczę pulę i już.

To jest oczywiście bardzo szczególny przypadek, ale powyższe zalety
można wykorzystać przy innych okazjach.

--
Paweł Kierski
n...@p...net

do góry

W dniu 13.09.2011 r. 16:18, Paweł Kierski pisze:
> W dniu 2011-09-13 13:27, kenobi pisze:
>> W obj-c jest cos co nazywa sie 'autorelease pools' i o ile rozumiem
>> jest to posredni stopien miedzy recznym zarzadzaniem pamiecia
>> (przez free/delete/release itp) a grabage collectorem.
[...]
> Świetnie się stosuje np. w przypadku, gdy w ramach jakiegoś
> separowanego przetwarzania musisz tworzyć dużo małych obiektów
> tymczasowych, a co najwyżej niektóre z nich będą potrzebne jako wyniki.
> (Ewentualny koszt kopiowania z puli do "innej" pamięci jest mały)
>
> Wtedy zysk jest duży:
> - alokacja z puli może być bardzo szybka (szczególnie, gdy dostęp do
> niej jest z jednego wątku, a obiekty są zbliżonych rozmiarów)
> - dealokacja puli jest jeszcze szybsza 8-)
> - na pewno wszystkie obiekty z puli zostaną usunięte - nie można mieć
> wycieków pamięci, o ile tylko zwolni się pulę (i nie ma referencji
> z obieków z puli, ale tym powinny zająć się ewentualne destruktory).
> Do tego zarządzanie jest bardzo proste - tworzę, tworzę,... potem
> niszczę pulę i już.
>
> To jest oczywiście bardzo szczególny przypadek, ale powyższe zalety
> można wykorzystać przy innych okazjach.
>
Ciekawe. Uczciwie pytam: czym rzecz się różni od TLS (Thread Local Storage)?

do góry

Znudzi sie kiedys toboie tworzenie pseudopostaci?
Nie wiem jak inni Ciebie odbieraja, ale ja uwazam, ze nie jest normalne
tworzenie, nie tyle wielu kont, co wielu postaci...

do góry

> Znudzi sie kiedys toboie tworzenie pseudopostaci?

> Nie wiem jak inni Ciebie odbieraja, ale ja uwazam, ze nie jest normalne

> tworzenie, nie tyle wielu kont, co wielu postaci...

Konta mam raptem 3 a to glownie po temu ze w onecie jest limit 10 postow na dobe. Nie
tworze zadnych 'postaci' tylko uzywam wielu 'ksyw' bo sa fajne.

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> W dniu 2011-09-13 13:27, kenobi pisze:

> > W obj-c jest cos co nazywa sie 'autorelease pools' i o ile rozumiem

> > jest to posredni stopien miedzy recznym zarzadzaniem pamiecia

> > (przez free/delete/release itp) a grabage collectorem.

> >

> >   NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

> >     //tu wywolaj funkcje

> >    [pool release];

> >

> > Dziala to tak ze wybrane (tj te obslugujace autorelelease) obiekty tworzone

> > po zalaczeniu poola sa rejestrowane i nie trzeba ich zwalniac - zostana usuniete

> > przy niszczeniu (albo drainowaniu) poola.

> >

> > Sam nie za bardzo znam sie ani na kwestiach dotyczacych gc ani tez i recznej

> > gospodarki pamiecia ale pamietam ze toczyly sie tu onegdaj dyskusje nt jednego i

> > drugiego a chyba nie byl  omawiany wlasnie ten posredni przypadek ([sam jestem

> > raczej zwolennikiem w wiekszosci statycznego podejscia - czyli mozna by to nazwac

> > jeszcze 'czwarta droga'); jakby co to chetnie uslysze zdania dotyczace tego
'posredniego'

> > miedzy gc a reczna gosp sposobu.

>

> Świetnie się stosuje np. w przypadku, gdy w ramach jakiegoś

> separowanego przetwarzania musisz tworzyć dużo małych obiektów

> tymczasowych, a co najwyżej niektóre z nich będą potrzebne jako wyniki.

> (Ewentualny koszt kopiowania z puli do "innej" pamięci jest mały)

>

> Wtedy zysk jest duży:

>  - alokacja z puli może być bardzo szybka (szczególnie, gdy dostęp do

> niej jest z jednego wątku, a obiekty są zbliżonych rozmiarów)

>  - dealokacja puli jest jeszcze szybsza 8-)

>  - na pewno wszystkie obiekty z puli zostaną usunięte - nie można mieć

> wycieków pamięci, o ile tylko zwolni się pulę (i nie ma referencji

> z obieków z puli, ale tym powinny zająć się ewentualne destruktory).

> Do tego zarządzanie jest bardzo proste - tworzę, tworzę,... potem

> niszczę pulę i już.

>

> To jest oczywiście bardzo szczególny przypadek, ale powyższe zalety

> można wykorzystać przy innych okazjach.

>

te pule o ktorych tu mowa to chyba jednak inne pule niz te w obj-c, wogole to chyba
obj-c na maku mozna polecic tym ktorzy
interesuja sie jezykami, bo to raczej ciekawy jezyk w pewnym sensie,np bardziej niz
np java

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

> obj-c, wogole to chyba obj-c na maku mozna polecic tym ktorzy
> interesuja sie jezykami, bo to raczej ciekawy jezyk w pewnym sensie,np bardziej niz
np java

obecnie interesuje sie core animation i chcialbym rozpykac jak to działa (tj co mozna
tym 'narysowac') niestety szefostwo bezmyslnie goni 'w produkcje'


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

W dniu 2011-09-13 16:53, n...@m...invalid pisze:
[...]
> Ciekawe. Uczciwie pytam: czym rzecz się różni od TLS (Thread Local
> Storage)?

Pula nie musi być przyporządkowana do wątku - opisałem tylko szczególny
przypadek, w którym dzięki takiemu założeniu implementacja (i operacje)
są tanie.

TLS to sposób przechowywania różnych zawartości dla per wątek, a pula
to sposób operowania na obszarze pamięci.

--
Paweł Kierski
n...@p...net

do góry