Article View: pl.comp.objects
Article #14713Re: pule obiektów
From: Sektor van Skijlen
Date: Thu, 25 May 2006 15:52
Date: Thu, 25 May 2006 15:52
65 lines
3981 bytes
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-mailReferences:
<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