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-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-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.


--
MN

"Marcin N" <marcin5.usun.wykasuj@onet.pl> wrote in message news:54702897$0$2844$65785112news.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-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-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.

On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <Pszemol@PolBox.com>
wrote:

"Marcin N" <marcin5.usun.wykasuj@onet.pl> wrote in message news:54702897$0$2844$65785112news.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-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-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...

Nonsens. Trzeba umiec programowac. Niestety, mlodzi miszczowie
klawiatury nie maja zielonego pojecia jak pisac programy w systemach
wyposazonych w garbage collector

A.L.

On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <Pszemol@PolBox.com>
wrote:

"Marcin N" <marcin5.usun.wykasuj@onet.pl> wrote in message news:54702897$0$2844$65785112news.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-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-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.

A.L.

A.L. <alewando@aol.com> wrote:

On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <Pszemol@PolBox.com>
wrote:

"Marcin N" <marcin5.usun.wykasuj@onet.pl> wrote in message news:54702897$0$2844$65785112news.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-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-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.

On Sat, 22 Nov 2014 17:12:51 +0000 (UTC), Pszemol <Pszemol@PolBox.com>
wrote:

A.L. <alewando@aol.com> wrote:

On Sat, 22 Nov 2014 07:03:07 -0600, "Pszemol" <Pszemol@PolBox.com>
wrote:

"Marcin N" <marcin5.usun.wykasuj@onet.pl> wrote in message news:54702897$0$2844$65785112news.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-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-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...

To jeszcze ciekawe jakie to sa programy

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)

Java jest akurat jezykiem silnie typowanym. Czy w C/C++ deklaruje sie
GDZIE w pamieci zmienna bedzie ulokowana? Jakos sobie nie przypominam.

ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
korzystanie z zasobow pamieci...

Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++. Czas
zycia obiektu w Javie kontroluje sie pzrez referencje - jak dlugo jest
referencja do obiektu, tak dlugo nei bedzie on "odsmiecony". Znane sa
techniki programwoania gdzie obiektow sie nei zwalnia (to znaczy,
zachowuje sie referencje), a trzyma zbior obiektow do pozniejszego
wykorzystania. Co parwda, takie techniki stosowano w czasach Javy 1.1,
teraz sa juz niepotzrebne.

Bez odsmiecacza nei da sie efektywnie napisac w miare skomplikowwnego
programu. Gdy w pewnym momencie mamy zaalokowane, powiedzmy, 1000
obiektow i tworaz one skomplikowany graf zaleznosci, reczena
dealokacja ani nie am sensu ani szans na powodzenie. Zwlaszcza jezeli
taka struktuar tworzona jest dynamicznie


Zreszta, C++ tez ma "proteze" odsmiecacza - patrz "smart pointers" w
bibliotece Boost. Powszechnie tez stosowany jest pzrez programistow
C++ odsmiecacz zwany Boehm garbage collector. Biblioteka taka

A.L.

"A.L." <alewando@aol.com> wrote in message news:ifm17a961q00ft2i33ag4otoe0jl4d84nl4ax.com...

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?

Zero komentarza?

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

To jeszcze ciekawe jakie to sa programy

Głównie jest to embedded computing (nie pecety).

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)

Java jest akurat jezykiem silnie typowanym. Czy w C/C++ deklaruje sie
GDZIE w pamieci zmienna bedzie ulokowana? Jakos sobie nie przypominam.

Na pecetach pewnie nie deklaruje się zwyczajowo, choć też można.
Ale na innych platformach często chcesz wiedzieć która zmienna
w ktĂłrej kostce siedzi bo np. ta kostka ma podtrzymanie bateryjne
a druga go nie ma...

ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
korzystanie z zasobow pamieci...

Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++.

Jasne. Są pointery/wskaźniki do fizycznej pamięci operacyjnej :-)

Czas
zycia obiektu w Javie kontroluje sie pzrez referencje - jak dlugo jest
referencja do obiektu, tak dlugo nei bedzie on "odsmiecony". Znane sa
techniki programwoania gdzie obiektow sie nei zwalnia (to znaczy,
zachowuje sie referencje), a trzyma zbior obiektow do pozniejszego
wykorzystania. Co parwda, takie techniki stosowano w czasach Javy 1.1,
teraz sa juz niepotzrebne.

W technice embedded unika się dynamicznej alokacji pamięci
i związanej z nią fragmentacją wolnej pamięci - to są urządzenia
które mają pracować bez restartu/resetu miesiącami, latami
i nic tam nie może się samo w czasie używania "bałaganić"
ani śmiecić żeby trzeba było śmieci zbierać...

Ale oczywiście smartfone nie zawsze można tak zakwalifikować.
Tym dzisiejszym smartfonom bliĹźej pecetowi niĹź komputerom embedded.

Bez odsmiecacza nei da sie efektywnie napisac w miare skomplikowwnego
programu. Gdy w pewnym momencie mamy zaalokowane, powiedzmy,
1000 obiektow i tworaz one skomplikowany graf zaleznosci, reczena
dealokacja ani nie am sensu ani szans na powodzenie. Zwlaszcza jezeli
taka struktuar tworzona jest dynamicznie

Ilość obiektów rzędu 1000 jest nieogarnięcia dla jednego człowieka, ale
dla komputera nie stanowią takie liczby obiektów żadnego problemu...
Co jest ważniejsze aby ogarnąć strukturę danych programu i stworzyć
jako programista mechanizmy którymi komputer za nas będzie tymi
obiektami zarządzał.

Zreszta, C++ tez ma "proteze" odsmiecacza - patrz "smart pointers" w
bibliotece Boost. Powszechnie tez stosowany jest pzrez programistow
C++ odsmiecacz zwany Boehm garbage collector. Biblioteka taka

Bibliotek różnych i środowisk można dołożyć tysiące i zmienia to
jedynie punkt widzenia dla aplikacji ktĂłra z biblioteki korzysta...
Ani nie masz gwarancji że ktoś zrobi alokację pomijając bibliotekę
ani nie masz gwarancji że sama biblioteka nie ma jakiegoś robala.

Ale chyba oddaliliśmy się nieco od tematu głównego...
Sugerujesz może że inicjujący ten wątek cytat ma błędy?
Z czymś się nie zgadzasz? Może podsumowałbyś ze swojej strony?

On Sat, 22 Nov 2014 13:17:03 -0600, "Pszemol" <Pszemol@PolBox.com>
wrote:

"A.L." <alewando@aol.com> wrote in message news:ifm17a961q00ft2i33ag4otoe0jl4d84nl4ax.com...

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?

Zero komentarza?

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

To jeszcze ciekawe jakie to sa programy

Głównie jest to embedded computing (nie pecety).

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)

Java jest akurat jezykiem silnie typowanym. Czy w C/C++ deklaruje sie
GDZIE w pamieci zmienna bedzie ulokowana? Jakos sobie nie przypominam.

Na pecetach pewnie nie deklaruje się zwyczajowo, choć też można.
Ale na innych platformach często chcesz wiedzieć która zmienna
w której kostce siedzi bo np. ta kostka ma podtrzymanie bateryjne
a druga go nie ma...

ze takie srodowisko promuje szybkie, niechlujne i bezmyslne
korzystanie z zasobow pamieci...

Niby dlaczego? Pamiec w Javie alokuje sie tak samo jak w C++.

Jasne. Są pointery/wskaźniki do fizycznej pamięci operacyjnej :-)

Czas
zycia obiektu w Javie kontroluje sie pzrez referencje - jak dlugo jest
referencja do obiektu, tak dlugo nei bedzie on "odsmiecony". Znane sa
techniki programwoania gdzie obiektow sie nei zwalnia (to znaczy,
zachowuje sie referencje), a trzyma zbior obiektow do pozniejszego
wykorzystania. Co parwda, takie techniki stosowano w czasach Javy 1.1,
teraz sa juz niepotzrebne.

W technice embedded unika się dynamicznej alokacji pamięci
i związanej z nią fragmentacją wolnej pamięci - to są urządzenia
które mają pracować bez restartu/resetu miesiącami, latami
i nic tam nie może się samo w czasie używania "bałaganić"
ani śmiecić żeby trzeba było śmieci zbierać...

Ale oczywiście smartfone nie zawsze można tak zakwalifikować.
Tym dzisiejszym smartfonom bliżej pecetowi niż komputerom embedded.

Bez odsmiecacza nei da sie efektywnie napisac w miare skomplikowwnego
programu. Gdy w pewnym momencie mamy zaalokowane, powiedzmy,
1000 obiektow i tworaz one skomplikowany graf zaleznosci, reczena
dealokacja ani nie am sensu ani szans na powodzenie. Zwlaszcza jezeli
taka struktuar tworzona jest dynamicznie

Ilość obiektów rzędu 1000 jest nieogarnięcia dla jednego człowieka, ale
dla komputera nie stanowią takie liczby obiektów żadnego problemu...
Co jest ważniejsze aby ogarnąć strukturę danych programu i stworzyć
jako programista mechanizmy którymi komputer za nas będzie tymi
obiektami zarządzał.

Zreszta, C++ tez ma "proteze" odsmiecacza - patrz "smart pointers" w
bibliotece Boost. Powszechnie tez stosowany jest pzrez programistow
C++ odsmiecacz zwany Boehm garbage collector. Biblioteka taka

Bibliotek różnych i środowisk można dołożyć tysiące i zmienia to
jedynie punkt widzenia dla aplikacji która z biblioteki korzysta...
Ani nie masz gwarancji że ktoś zrobi alokację pomijając bibliotekę
ani nie masz gwarancji że sama biblioteka nie ma jakiegoś robala.

Ale chyba oddaliliśmy się nieco od tematu głównego...
Sugerujesz może że inicjujący ten wątek cytat ma błędy?
Z czymś się nie zgadzasz? Może podsumowałbyś ze swojej strony?

Cytat jest taki sobie bo nie mowi ZCO bylo mierzone i w jakich
warunkach

Lepsze zrodlo jest tutaj

http://www.devahead.com/blog/2011/12/coding-for-performance-and-avoiding-garbage-collection-in-android/

A.L.

"A.L." <alewando@aol.com> wrote in message news:jcu17admr7kielbuephp208lvcq0tk5jsf4ax.com...

Ale chyba oddaliliśmy się nieco od tematu głównego...
Sugerujesz może że inicjujący ten wątek cytat ma błędy?
Z czymś się nie zgadzasz? Może podsumowałbyś ze swojej strony?

Cytat jest taki sobie bo nie mowi ZCO bylo mierzone i w jakich
warunkach

Lepsze zrodlo jest tutaj

http://www.devahead.com/blog/2011/12/coding-for-performance-and-avoiding-garbage-collection-in-android/

No i co z niego dla Ciebie wynika? Zrewidowałeś swe stanowisko?

On Sat, 22 Nov 2014 16:19:44 -0600, "Pszemol" <Pszemol@PolBox.com>
wrote:

"A.L." <alewando@aol.com> wrote in message news:jcu17admr7kielbuephp208lvcq0tk5jsf4ax.com...

Ale chyba oddaliliśmy się nieco od tematu głównego...
Sugerujesz może że inicjujący ten wątek cytat ma błędy?
Z czymś się nie zgadzasz? Może podsumowałbyś ze swojej strony?

Cytat jest taki sobie bo nie mowi ZCO bylo mierzone i w jakich
warunkach

Lepsze zrodlo jest tutaj

http://www.devahead.com/blog/2011/12/coding-for-performance-and-avoiding-garbage-collection-in-android/

No i co z niego dla Ciebie wynika? Zrewidowałeś swe stanowisko?

jakie stanowisko? ja mowie tylko ze jak chce sie uzywskac dobar sparwnosc, to tzreba
wiedziec jak to robic. Nie mozan programwoanc "na pale"

A.L.

"A.L." <alewando@aol.com> wrote in message news:ps327a5j5eq28n86ughbcb0p6r4orcb6624ax.com...

No i co z niego dla Ciebie wynika? Zrewidowałeś swe stanowisko?

jakie stanowisko?

ja mowie tylko ze jak chce sie uzywskac dobar sparwnosc, to tzreba
wiedziec jak to robic. Nie mozan programwoanc "na pale"

To obowiązuje przecież zawsze i wszędzie - niezależnie od tego
jakiego narzędzia się używa i w jakim środowisku tworzy programy.
Właśnie o tym mówiłem że języki w których środowisko zdejmuje
z programisty odpowiedzialność za troszczenie się o zarządzenie
pamięcią mogą prowokować do niechlujnego pisania programów.

"Co? Limity pamięci? A niech się kompilator/interpreter/VM martwi.
A sobie radośnie będę tworzył program a inni niech sprzątają" :-)

Niestety nigdzie tak nie ma.
Ale to rozmowa na news:pl.comp.programming a nie tutaj.

UĹźytkownik "Pszemol"  napisał w wiadomości grup dyskusyjnych:m4qned$86m$1@dont-email.me...

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

To jeszcze ciekawe jakie to sa programy

Głównie jest to embedded computing (nie pecety).

Tak myślałem, co drugiemu elektronikowi się zdaje, że ma duże skillsy programistyczne bo mu programy działają. Nie czarujmy się, to są programiątka. Tyci, tyci.

"Ghost" <ghost@everywhere.com> wrote in message news:54710a34$0$20327$65785112news.neostrada.pl...

UĹźytkownik "Pszemol"  napisał w wiadomości grup dyskusyjnych:m4qned$86m$1@dont-email.me...

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

To jeszcze ciekawe jakie to sa programy

Głównie jest to embedded computing (nie pecety).

Tak myślałem, co drugiemu elektronikowi się zdaje, że ma duże skillsy programistyczne bo mu programy działają. Nie czarujmy się, to są programiątka. Tyci, tyci.

Nie masz podstaw do wyciągania wniosków o rozmiarze moich programów.
No chyba Ĺźe dla Ciebie "embedded" oznacza tylko 8-bitowego PICa :-)))))
Ale wtedy to juĹź nie jest mĂłj problem Ĺźe masz ograniczone horyzonty.

UĹźytkownik "Pszemol"  napisał w wiadomości grup dyskusyjnych:m4r29f$n4a$1@dont-email.me...

Tak myślałem, co drugiemu elektronikowi się zdaje, że ma duże skillsy programistyczne bo mu programy działają. Nie czarujmy się, to są programiątka. Tyci, tyci.

Nie masz podstaw do wyciągania wniosków o rozmiarze moich programów.

Mam pewność, że nie napisałeś się w życiu dużo kodu.

Pszemol wrote:

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

i to by było na tyle jeśli chodzi o Twoje doświadczenie. Jeszcze się
musisz dużo nauczyć

--
mst <at> gazeta <.> pl
"-Mam lęk gruntu! -Chyba wysokości? -Wiem co mówię. To grunt zabija!" T.Pratchett

UĹźytkownik "Pszemol"  napisał w wiadomości grup dyskusyjnych:m4qg6j$v7i$1@dont-email.me...

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

Wpisz to sobie w CV.

Pszemol wystukał, co następuje:

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.

Borze... Ty na prawdę jesteś ignorantem... primo - java to nie jvm; po wtóre - głupie ARC jest i w obj-c i w swifcie. Coś dzwoni, nawet wiesz że może to być kościół... a może jednak krowi dzwonek

"W" <wu@wu.pl> wrote in message news:XnsA3EDDA07CBC32wuathomeat.home...

Pszemol wystukał, co następuje:

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.

Borze... Ty na prawdę jesteś ignorantem...

Nie podaję się wcale za eksperta. Zwłaszcza nie eksperta od Java.

primo - java to nie jvm;

A kto tu twierdził i gdzie, że Java to jest to samo co java virtual machine?

po wtóre
- głupie ARC jest i w obj-c i w swifcie.

A kto tu twierdzi że nie ma?
Jak widać działa jednak dużo lepiej niż ten w Andku, skoro taka jest
duża różnica w wydajności między Andkiem a iOS że trzeba 3x
więcej RAMu w Andku aby zrównać się z iOS z 1Gb RAMu.

W dniu 2014-11-22 o 21:26, W pisze:

Borze... Ty na prawdę jesteś ignorantem... primo - java to nie jvm; po wtóre
- głupie ARC jest i w obj-c i w swifcie. Coś dzwoni, nawet wiesz że może to
być kościół... a może jednak krowi dzwonek

A co z kólturą dyskusji? I poszanowaniem innego człowieka?



--
pozdrawiam
Piotr
XLR250&bmw_f650_dakar