🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.objects
Article #14713

Re: pule obiektów

#14713
From: Sektor van Skijlen
Date: Thu, 25 May 2006 15:52
65 lines
3981 bytes
Dnia Thu, 25 May 2006 16:04:32 +0200, Jarek Ratajski skrobie:
> > Po pierwsze, zupełnie nie rozumiem, dlaczego takie znów niemożliwe byłoby
> > przyjęcie takiej strategii, że środowisko jest takie jakie, jak odśmiecane,
> > tylko że nie dokonuje się automatyczne trackowanie obiektów, a jest ono
> > uruchamiane dopiero w momencie zrobienia jawnego 'delete'. I to też
> > niekoniecznie za każdym, tylko z odpowiednią amortyzacją. Włączając w to
> > również możliwość przesuwania obiektów.
> Można tak by zrobić. Zostaje tylko pytanie po co.

Po to, żeby przydział i zwolnienie pamięci były mniej zasobożerne.

> Po to żeby nie 
> odśmiecały się obiekty jak ktoś zapomni o delete ?
> I wtedy lepiej będzie pisać:
>          new Object().delete(); //żeby środowisko trackowało :-)

Nie. Po prostu delete object; jak normalnie w C++.

A trackowanie obiektów w tym przypadku odbywałoby się tylko jako
"zabezpieczenie przed wyciekami". W przypadku, gdy na każdym obiekcie musisz
jawnie zrobić "delete", trackowanie może co najwyżej pomóc na defragmentację.

> > Po drugie, najefektywniejszym sposobem zarządzania pamięcią obiektów,
> > szczególnie dużą ilością małych obiektów o krótkim czasie życia, pozostaje
> > alokator specjalizowany (pula przeznaczona dla obiektów tylko jednego typu).

> Najefektywniejszym w jakim sensie ?
Zużycia czasu procesora na czynności związane z przydziałem i zwalnianiem
pamięci przeznaczonej na obiekty.

> Np. w sesnie zużycia CPU to prawdopodobnie najefektywniejszym jest 
> dokupienie kilku terabajtów pamięci i wyłaczenie gc :-)

Pomińmy to milczeniem. Jeśli się nie zgadzasz - proszę bardzo, masz pole do
popisu, tylko konkretnie, proszę.

> > To jest też prawda, że odśmiecacz zapobiega wyciekom pamięci
> nie
> > i zmniejsza
> > niebezpieczeństwo istnienia wiszących wskaźników, 
> tak
> > ale związku z efektywnością
> > przydzielania pamięci nie ma to za grosz.

> ?

Czego w powyższym zdaniu nie zrozumiałeś?

> > Można by zadać pytanie, dlaczego w takim razie w C++ wciąż stosuje się
> > "malloc-based" przydzielanie pamięci (taka jest niestety praktyka, nie tylko w
> > gcc). Nie wiem. Może ktoś z grupowiczów mógłby przedstawić jakieś potencjalne
> > problemy z zaimplementowaniem takiej metody, jak opisana w p1?

> bo to by już nie było C++ tylko Java-- ?

Taaa... może wybitny specjalista od języków wszelakich p. Andrzej Lewandowski
podpowie ci, w jaki sposób w Javie zapewnia się deterministyczność usuwania
obiektów.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"
Technical Details
Message-ID: <e54jr6$5eg$3@kujawiak.man.lodz.pl>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!newsfeed.pionier.net.pl!news.man.lodz.pl!not-for-mail
References: <e524va$uk4$1@news.onet.pl> <0dc97213pniht75f98ui5ikrca3m5i1rc4@4ax.com> <e5405a$kf3$1@kujawiak.man.lodz.pl> <e54dbo$6k$1@news2.ipartners.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!mat.uni.torun.pl!news.man.torun.pl!newsfeed.pionier.net.pl!news.man.lodz.pl!not-for-mail
From: Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
Newsgroups: pl.comp.objects
Subject: Re: pule obiektów
Date: Thu, 25 May 2006 15:52:06 +0000 (UTC)
Organization: LODMAN - Metropolitan Area Network in LODZ, Poland
Lines: 65
Sender: Michal Malecki <sektor@zly.kis.p.lodz.pl>
Message-ID: <e54jr6$5eg$3@kujawiak.man.lodz.pl>
References: <e524va$uk4$1@news.onet.pl> <0dc97213pniht75f98ui5ikrca3m5i1rc4@4ax.com> <e5405a$kf3$1@kujawiak.man.lodz.pl> <e54dbo$6k$1@news2.ipartners.pl>
NNTP-Posting-Host: zly.kis.p.lodz.pl
Mime-Version: 1.0
X-Trace: kujawiak.man.lodz.pl 1148572326 5584 212.191.89.2 (25 May 2006 15:52:06 GMT)
X-Complaints-To: abuse@man.lodz.pl
NNTP-Posting-Date: Thu, 25 May 2006 15:52:06 +0000 (UTC)
User-Agent: tin/1.6.2-20030910 ("Pabbay") (UNIX) (SunOS/5.9 (sun4u))
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit