A.L. <a...@a...com> wrote:
> On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <P...@P...com>
> wrote:
>
>> "Marcin N" <m...@o...pl> wrote in message
>> news:54702897$0$2844$65785112@news.neostrada.pl...
>>> W dniu 2014-11-22 06:41, Pszemol pisze:
>>>> Ano tu jest to wyjaśnione - przyczyna dla której Android wymaga
>>>> dużo więcej pamięci do szybkiej pracy jest znowu Java i garbage
>>>> collection:
>>>> http://www.quora.com/How-come-the-iPhones-1-GB-RAM-i
s-touted-to-be-able-to-compete-with-more-than-2-GB-R
AM-of-Android-phones/answers/7061202
>>>>
>>>>
>>>> Dopiero Android z 3G ramu na pokładzie będzie pracował tak szybko
>>>> jak iPhone z 1G ramu - a mniej kostek pamięci to mniej prądu z baterii!
>>>
>>> Widać, jak niechlujnie pisane są programy w dzisiejszych czasach.
>>> Potrzebne są gigabajty, żeby użyć jakichś prostych aplikacji, które
>>> mogłyby się spokojnie zmieścić w megabajtach.
>>
>> Wiesz co Ci powiem - zawsze mi mówiono że Java jest nieefektywna
>> i że ten cały wychwalany przez nielubiących wskaźników w C/C++
>> mechanizm automatycznego zarządzania pamięcią jakoś tam działa
>> ale niezbyt efektywnie - więc nie jest to dla mnie nowością, że coś
>> co wykorzystuje Javę nie będzie efektywne, będzie rozrzutne jeśli
>> chodzi o pamięć czy inne zasoby procesora...
>> Co mnie zszokowało to jak dowiedziałem się JAK BARDZO jest to
>> nieefektywne i jak bardzo marnotrawne. Spodziewałem się czegoś
>> na kształt 10-20% a nie że stosunek całej pamięci procesora do tej
>> używanej części ma być jak 4:1 czy nawet jak piszą 8:1 aby to szybko
>> działało... To jest dla mnie po prostu tak absurdalne że wręcz śmieszne.
>
> To jest fragment dyskusji na temat jezyka Swift:
>
> Garbage collection: It's likely that Apple considered that ARC was
> good enough in most situations, and it makes interoperability with
> Objective-C (compatibility in terms of memory management) much easier
> to handle. Still, this would give me trouble. Lack of proper garbage
> collection means more memory bugs to hunt down.
>
> JEzyk Swift (podobnie jak Objectiwe C) MA odsmiecacz, konkretnie
> implementacje zwana "reference counting". Ma sie to tak do
> wspolczesnych odsmiecaczy jak woz drabiniasty do Mercedesa. To jest
> wynajazek spzred 30 lat.
>
> Jednoczesnie, jak pisza wyzej, brak porzadnego odsmeicacza kreuje
> problemy z wyciekaniem pamiei ("memory leaks") i skutkuje zwiekszonymi
> kosztami i czasem niezbednym na zrobienie i pzretestowanei aplikacji.
> Generalnie, gospodarka pamiecia w systemach bez GC jest mniej
> efektywna niz w systemach z GC i skutkuje aplikacjami wymagajacymi
> wiecej pamieci.
>
> Zapewne dlatego wsztsko w Apple jest drozsze. Podbnie jak drozszy
> bylby stol robiony heblem i krajzegoa w porownaniu ze stolem zeobionym
> przy pomocy automatycznych obrabiarek
>
> Wspolczesne GC (zwlaszcza w javie) dostarczane sa w wersji "parallel".
> Oznacza to ze GC moze byc wykonywany w osobnym watku, "w tle"
> aplikacji. W koncu, gdy pzrecietny procesor ma 4 "cores" tzreba je
> jakos wykorzystac.

Czy autor tych słów na ktore się tu powołujesz jest dla Ciebie jakimś
autorytetem?
Bo nie przytoczyłeś źródła tej wypowiedzi - może autor nie wie o czy mówi?

Ja mam ponad 20-letnie doświadczenie w programowaniu w C/C++ i żadna pamięć
w moich programach nie wycieka...

Mam pewne przeczucie na podstawie pracy w innych językach programowania
gdzie nie deklaruje się rozmiaru/typu zmiennej ani nie alokuje się dla niej
specyficznego obszaru w pamieci RAM (ale brak bezposredniego doswiadzczenia
w Javie) ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
korzystanie z zasobow pamieci...

Jezykiem Swift chetnie sie zainteresuje.