🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.objects
Article #4987

Re: Glos na temat zasad dyskusji naukowej

#4987
From: lewando
Date: Sat, 20 Feb 1999 17:22
57 lines
3225 bytes
Date sent:      	Sat, 20 Feb 1999 16:23:11 +0100
Send reply to:  	objects@sprocket.ict.pwr.wroc.pl
From:           	Sektor van Skijlen <sektor@spam.org>
To:             	Multiple recipients of list <objects@sprocket.ict.pwr.wroc.pl>
Subject:        	Re: Glos na temat zasad dyskusji naukowej

> W ostatnim odcinku, lewando@ibm.net naskrobal:
> : Jak sie wykonuje drugie podstawienie, to poprzednia zawartosc B1 
> : zostaje odsmieciowana. Tak wiec porownanie 995 i 4158 daje nam 
> : poglad o nakladzie pracy wykonywanej przez odsmiecacz. 
> 
> Oczywiscie, ze takie odsmiecanie jest marnowaniem efektywnosci. I szczerze
> mowiac mnie to nie dziwi. Biorac pod uwage, ze zwolnienie pamieci zajmuje
> mniej wiecej tyle samo czasu, co jej przydzielenie, widac, ze jak samo
> zwolnienie obiektu, gdy robi to odsmiecacz, wykonuje sie ok 3 razy wolniej,
> niz jego utworzenie, to ile mocy procesora zzera samo GC. I co komu po tym, ze
> programista ma mniej zmartwien ? A co z programami, ktorych NIE WOLNO
> spowolnic w pewnych krytycznych momentach ? Argument na czyja korzysc tym
> razem ?
> 

Na moja. Ze nie ma odsmiecaczy do "nie zatrzymuja programu". 
Oraz o tym, ze czasem odsmiecacz nie robi 'dobrej roboty" a 
wrecz przeciwnie. Oraz za tym, ze chcialbym miec mozliwosc 
kontrolowania tego jak co sie robi. Oraz przeciw argumentowi ze 
"Java lepsza niz ... bo ma odsmiecacz".

> : Cala sprawa nie jest naukowa i hipotetyczna. W dosyc duzym 
> : projekcie musialem napisac swoja wlasne kolekcje tak aby 
> : uniknac odsmiecania. Poniewaz w Smalltalku nie mozna 
> : odsmiecania wylaczyc, tzreba bylo zrobic tak, zeby nie 
> : nastepowala dereferencja. Niepotrzebne obiekty trzeba bylo 
> : trzymac w specjalnej kolekcji, skad sie je pobieralo jak sie chcialo 
> : utworzyc nowy obiekt. Naprzeklinalem sie odsmiecacza co 
> : niemiara i niejeden siwy wlos w mojej brodzie stad pochodzi...
> 
> Czy bylo to moze cos podobnego, co niedawno opisalem ?
> 

Mniej wiecej dokladnie, moze nie dokladnie tak samo ale dokladnie 
podobnie. Dla obiektow tego samego "typu" (cokolwiek slowo "typ" 
oznacza) buduje sie zbior niepotrzebnych obiektow. Alokator 
najpierw sprawdza czy nie ma wolnego obiektu w tym zbiorze. 
Dealokator zwraca zawsze do zbioru, nigdy do sterty. Troche 
administracji jest potrzebne zeby ten zbior nie urosl do zbyt 
duzych rozmiarow, ale ta administracje (zwiazana z 
odsmiecaniem) mozna robic na zadanie w tym momencie gdy 
wiadomo ze mozna sobie na taka rzecz pozwolic.

> : Stad wniosek, ze nie wszystko zloto co sie swieci....
> 
> Smieci :*))
> 

Poniekad.

A.L.
Technical Details
Message-ID: <199902201704.RAA38338@out2.ibm.net>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!news.wnaft.agh.edu.pl!news.memax.krakow.pl!paa.gov.pl!news.swierk.pl!news.icm.edu.pl!ict.pwr.wroc.pl!m2n-gate.okapi.usenet.pl

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!pingwin.icm.edu.pl!agh.edu.pl!news.wnaft.agh.edu.pl!news.memax.krakow.pl!paa.gov.pl!news.swierk.pl!news.icm.edu.pl!ict.pwr.wroc.pl!m2n-gate.okapi.usenet.pl
From: lewando@ibm.net
Newsgroups: pl.comp.objects
Subject: Re: Glos na temat zasad dyskusji naukowej
Message-ID: <199902201704.RAA38338@out2.ibm.net>
Date: 20 Feb 99 17:22:07 GMT
Sender: objects@sprocket.ict.pwr.wroc.pl
Organization: Lista dyskusyjna objects@sprocket.ict.pwr.wroc.pl
Lines: 59
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit