Lényegesen kevesebb memóriát használ majd a Firefox 7 mint a FF6 (és 5 és 4)

Mozilla

Úgy fest, hogy lesz gyümölcse a Mozilla által korábban bejelentett Memshrink munkacsoport munkájának. A Memshrink csapat azért alakult, hogy csökkentse a népszerű, nyílt forrású böngésző memóriahasználatát. A Mozilla-nak dolgozó Nicholas Nethercote friss blogbejegyzése szerint a Firefox 7 gyors lesz, sokkal kevesebb memóriát használ mint elődjei, a memóriaszivárgás probléma is megoldódni látszik. A tab bezárásakor több memória fog felszabadulni és stabilabb lesz mint az elődei.

( saxus | 2011. 08. 11., cs – 22:11 )

"és stabilabb lesz mint az elődei"

Az nagyon jó lenne, mert mostanság (5.x óta leginkább) nekem Windowson kb. akkor szokott leginkább befagyni, mikor egy indítás után azt mondom neki, hogy új munkamenet indítása ahelyett, hogy visszaállítaná...

Leléptek a fejlesztők aztán csak a marketingesek maradtak vagy mi?

----------------
Lvl86 Troll

én már rég, FF felvett pár marketingest, azok meg nyomatnak mindent most.
Lényeg hogy minden verzióho kell egy jó szöveg.

Memoria használatról már nem szólok semmit, mert fejlesztők levágják a fejem, elhiszem nincsenek megfizetve nem ez a dolguk hogy optimalizáljanak, ha a user úgy is kenyér árba veszi a ramot.

Így jutunk el majd oda 2 év mulva hogy már 4 magos cpu kell mobilba meg 3 Gb ram, szánalom szerintem.. de mind1

Így jutunk el majd oda 2 év mulva hogy már 4 magos cpu kell mobilba meg 3 Gb ram, szánalom szerintem.. de mind1

Ez ennel joval osszetettebb.

Egy csak html-t tudo browser-t pl. az Opera irt j2me-ben. De manapsag egy browser iszonyat sokmindent tamogat. CSS, kep/hang/video file-ok, https, ftp, opentype fontok, blabla ..., vagy hogy a legfontosabbat a vegere hagyjam: javascript, JIT VM-el (ami tekintve a javascript igencsak dinamikus voltat, nem semmi). Mindezt persze szeparalt processzekben, plugin-ekkel (flash, pdf, stb...), extension-okkel (amiknek ugye be kell epulniuk a bongeszobe, tehat legyen sok-sok absztrakcio es API a bongeszo design-jaban), biztonsagosan es multi-threadelve (hogy reszponziv UI-t adjon).

Aztan meg jon a user es anyaz, hogy dehat ez neki sok memoriat/cpu-t eszik. Erre mondana egy firefox/chrome/... developer, hogy "elmentek ti a *******" :)

( b | 2011. 08. 11., cs – 22:29 )

Feltalálták a spanyol viaszt.

__attribute__((packed))

--
GPLv3-as hozzászólás.

Nagyon +1. Pláne a fiatalokból. (Én már mint viszonlag öreg róka) A memóriát feneketlen pöcegödörnek tekintik. Amibe belemehet minden vacak. Minap került a szemem elé, egy .net kód amit C-síteni szeretnénk, lévén lassú mint a ....... Na szerintem a lassúságban nem (csak) a .net és a környezete a ludas. Eszméletlen mértékű erőforráspocsékolás van benne. Serintem kicsit átgyomlálva dotnet-el is egész gyors lenne. Ettől függetlenül C-lesz belőle, mert az fordítható a linuxos szerverünkre.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Meglehetősen nehéz olyan alkalmazást írni, amelyik minden platformon optimális. Telefonon is jól megy, meg a szerveren is. A belső cache-ek méretével lehet ugyan szórakozni, de ez még azért semmi.

Képzeld el, hogy pl. 10.000 string-et rendezni kell. A string-ek unicode-ban vannak, de a glibc-s rendezőalgoritmus UTF-8-at kíván.

- Telefonos megoldás: 10.000x10.000 Unicode->UTF 8 konverzió, lassú
- Szerver megoldás: 10.000 stringet 1-szer konvertálod, a memóriában eltárolod, ezt hasonlítod össze (memóriaigényes)

Tipikus példája annak, amikor a sebességért memóriával fizetsz. Éppen ezért hiába van neked 16 Giga RAM-od, ha a program 64 megán is elfut, akkor nem fog belőle szinte semmit kihasználni.

Az UTF-16 is egy Unicode-enkódolás, az UCS-2 és az UCS-4 és az UTF-32 , UTF-1 mellett. A Unicode-nak semmi köze a használt kódoláshoz. A Unicode semmi más, mint egy szép hozzárendelés nemnegatív egész számok (aka Unicode code point) és írásjelek között. Az, hogy ezt a hozzárendelést miként kell a számítógépen ábrázolni (milyen bytesorozatként), na azt definiálja sok-sok encoding, ami létezik Unicode-hoz.

A sok memóriafogyasztás és a sebesség között van korreláció. Ha el kell kezdeni swap-pelni, az kihatással van a sebességre is.

Arról nincs információm, hogy ha 500 megát foglal egy procesz (nincs swap), lassabb-e, mintha 50 megát fogyasztana. Ha valaki tudja, mesélje el.

(elképzelhetőnek tartom, hogy bizonyos malloc/free implementációk lassabbak 2.000.000 objektumra, mint 2-re, a malloc/free meg ugye egyébként is lassú művelet)

Ha épeszűen használja a memóriát ez akkor van (mint gondolom azt te is nagyon jól tudod). Nekem pl nagyon tetszik az ultimate++ memóriakezelése, a használata elején futra érzés volt, hogy komplett file-ket tölt be a memóriába (ez voltz az egyik furcsaság), de gyak 1 pointer dobásával törölve is van..... Megszoktam. Kényelmesen elérhetővé válik stb (mondjuk nagy programok írására nem az igazi, külső libek használata, amihez nincs írva plugin, agyhalál....), de a memóramodellje szerintem nagyon jó.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

"Főleg a memleak a gázos egyébként."

No meg a memória-fragmentáció, amiről sokan elfeledkeznek.

Sok kicsi malloc (amit gyönyörűen elrejt az objektum-orientált szemlélet a konstruktorok mögé), széttördeli a memória-foglalási térképet, amitől a későbbi foglalások nem találnak olyan könnyen elég nagy méretű szabad területet, lassul a futás is ettől, ...

Azert a sok kicsi objektum altalaban egyben szabadul fel egy nagy terulette. Nem veletlen van a .NET-ben generaciozo GC (pontosabban a default GC), ahol 3 generaciora osztja fel az objektumokat, mert altalaban ugy is a legujabb generaciot fogja felszabaditani tipikusan legeloszor, amit meg megse azt tolja regebbi generaciob.

(Ez foleg a sok ideiglenes objektum miatt talaltak ki)

----------------
Lvl86 Troll

Ahhoz képest kicsit sokat emlegeti a könyvében az ojjektumokat.

Tény, hogy nem 100%-osan OOP, mint egy C# vagy egy Java, de minden megvan a nyelvben, ami ahhoz kell, hogy valaki objektum orientáltan tudjon benne dolgozni ronda hackok nélkül.

Az, hogy nem tisztán OOP az következik abból is, hogy a C-re építették rá, hasonlóan, mint egy ObjectPascal nyelvjárásnál (pl. Delphi), ahol a Pascal nyelvre épíették rá az OOP-t.

----------------
Lvl86 Troll

A C++ TÁMOGATJA az objektumorientált paradigmát. Egy NYELV attól lesz OO, ha minden ojjektum benne. Ez például a Python. A Java/C# sem teljesen OO, a C++ meg főleg nem. A C++ teljesen tisztán csak támogatja, lehetővé teszi. Ha nem akarod, egyáltalán nem jelenik meg benne.
----
Hülye pelikán

Objektum orientált. Nekem ez a szó azt jelenti, hogy az objektumok felé orientálódik, törekszik arra, hogy te OOP-t művelj. A Java ilyen, hiszen kényszerít, hogy minden amit csinálsz, class legyen. A C++ nem ilyen, persze, a létrehozásának a célja az volt, hogy C with classes, de azóta már nagyot haladtunk, és már a legelején sem az volt a fő szempont, hogy márpedig én most csinálok egy OO nyelvet, hanem hogy csinálok egy ERŐS nyelvet, aminek gazdag az eszközkészlete, és minden projekt úgy használja, ahogy neki a legjobb. Szerintem a C++ nem orientálódik az objektumok felé.
----
Hülye pelikán

A QT megoldotta azzal, hogy láncbafűzi az objektumokat.

Amikor egy ablak (szülő) bezáródik, akkor gyermekek automatikusan törlődnek. A parent pusztulása a child-okat is kinyírja. Firefox alatt pl. egy tab bezárásával automatikusan fel kellene szabadítani mindent, amit a tab foglalt le.

Belül a QT managed pointereket kezelt, szóval ha más objektum referenciát tartott valamelyik felszabadított gyermekre, akkor azt törölte (lista), vagy nullázta (hash).

A QT3 nem is ezért fürdött be. A probléma az volt, hogy rengeteg kisméretű objektumot foglaltak le, csomó referenciával és egy ablak bezárása időnként az 1s-t is elére (gondolj bele, hogy van egy 1000 elemű lista, ahol minden elem még lefoglal 10 QString-et, meg a destruktorok hívogatása, kiszedése listából, hash-ből,...).

Szóval a delete az rohadt lassú volt, de biztonságos és minimalizálta a leak-et. QT4-ben már sok osztály nem QObject, azaz nem hívódik meg a destroy() signal és nem kezd idétlenkedni felszabadításnál. QT4-ben átgondolták, hogy hogyan lehetne a malloc/free-k számát minimalizálni.

Azért new mégiscsak történik, a stacken létrehozott objektum által (általában, hacsak nem másfajta R-ről beszélünk). Különben csak szimplán automatikus változónak hívjuk. De én sem értem, mitől lenne ez RAII, most csak azért, mert smart pointerszerűségeket használ?
----
Hülye pelikán

( wince | 2011. 08. 11., cs – 23:30 )

A végén még vissza is ad 1Gb-ot, nem hogy megenne. :)

( Lacyc3 v | 2011. 08. 12., p – 00:31 )

És most tényleg, élesben használom az Aurora-t és semmi bajom vele. Gyors, stabil és nem eszi meg a gépet.

Az a baj, hogy ez alapvetően semmit nem jelent. Minden firefoxos hírnél van valaki, aki azt mondja hogy fúú ez aztán remek, és más, aki szerint szarabb mint eddig volt.
Részemről - bár annyira nem figyelek az ilyenekre - semmi változást nem veszek észre. Se sebességbe, se memóriahasználatba. Használom, működik, eszik 1-1,5G ramot, néha crashel egyet nem tudom miért, aztán újraindítom és megy tovább. Kb. ugyanezt tapasztaltam 3.x, de lehet már 2.x alatt is, mint most.
--
Discover It - Have a lot of fun!

Most megijedtem. Basszus, valami nincs rendben nálam! Hiszen én is Firefoxot használok, de csak 512MB RAM-om van, akkor ebben hogyan futhat jól a FF, ha neked megeszik 1-1.5 gigát?! Pedig ezen a nálam levő 512 MB-on osztoznia is kell más alkalmazásokkal, nem sajátíthatja ki az egészet...

Eh, ne szídjátok már annyit a rókát. Szerintem tök jó. Vagy ha szar is de mások méginkább.
-------------
Használj GoboLinuxot: http://mek.oszk.hu/05800/05895/
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Nálam a megnyitott 37 tab 400 mega körül eszik.

A Firefox ott cseszte el, hogy bevezette a Tabbed Browsing-ot. Természetes, hogy ha 500 tab nyitva van, oda memória is kellene. A user-ek elég gyorsan képesek elérni a memóriahatárt.

Ha minden firefox külön ablakban futna, a Windows előbb utóbb nem engedne újakat nyitni, így a memóriaproblémához sem jutnál el.

:)

Lehet hogy én azért nem tapasztalok különösebb problémákat, mert nálam az is ritka, hogy akárcsak 15 tab is legyen egyszerre nyitva. (Általában 6-8 tabbal nyomulok). De szerintem aki ennél több tabot használ, az különben is perverzgyanús, és magára vessen.
-------------
Használj GoboLinuxot: http://mek.oszk.hu/05800/05895/
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
:::A #86-os sorszámú hivatalosan bejegyzett GoboLinux felhasználó

Van, amikor elkerülhetetlen. Képzeld el, hogy dolgozol, dokumentációt nézel, és nem akarsz fejben tartani nemtudoménhány linket ahhoz, hogy elérd a megfelelő függvények dokumentációját, viszont gyorsan váltogatsz egyikről a másikra. Plusz még az oldal, amit esetleg fejlesztesz, ésatöbbi. Tud ebből sok tab lenni.

Én bookmarkba csak olyat teszek, ami tartósan érdekel. Pl. találok valami jó howtot vagy leírást, ami bármikor kellhet.
Tabon meg olyanok vannak nyitva, amit meg kéne nézni, el kéne olvasni egyszer, esetleg az "érdekes lehet" kategória. Ezeket nem teszem bookmarkba. Elolvasni pedig nem mindig van időm :). Van hogy egy ilyen tab hónapokig nyitva van.
--
Discover It - Have a lot of fun!

Sajnos pedig jogos a fenti panasz. Ameddig van mit, addig zabál a FFox. Jobb esetben észreveszi magát, rosszabb esetben tele nyomja a swapot. Múltkor egy éjszakára nyitva maradt egy FFox (talán index-el), reggelre 1.5GB ramot és 2GB swapot evett.

A 7-essel nem tapasztaltam ilyet.

En nem mertem vagy figyeltem konkretan semmit, viszont tervben volt egy alaplap + CPU + memoria csere az asztali gepben, mert tetu lassu volt es neha mar majd szetutottem az idegessegtol. Viszont tegnap du. frissitettem 7.0-ra az FF-et is es a TB-ot is, avagy azt a ket alkalamazast, ami mindig fut. Most is megesznek 153 es 138 megat, de jelentosen gyorsabb es azota egyelore nem lassult be hosszu masodpercekre. Tehat lehet megsporolom a korszerusitest, vagy szimplan veszek 1G RAM-ot azt annyi.

( waiter | 2011. 08. 12., p – 10:48 )

...ééés az Acid3 teszttel mi lesz? Egy jó ideje azért illene már 100% támogatottnak lenni ebben is böngészőfronton. Sajnálatomra és legnagyobb várakozásom ellenére a relatíve friss FF5 még mindig csak 97/100. A Chrome már ebben is veri a Tűzrókát. Ejjejj.

- waiter -

Ne sajnáld... :) Sose fogja elérni és nem is kell! Az Acid3 már kicsit elavult. Az a maradék 3 pont a SVG font támogatottságé lenne ami már teljesen felesleges a WOFF font standard implementálása után.
Mythbusting: Why Firefox 4 won’t score 100 on Acid3

http://centralcomputer.hu | Számítástechnikai szaküzlet, Szerviz és Internet kávézó

( atya | 2011. 08. 12., p – 14:11 )

Egy hasznos tipp memóriazabálás ellen (nézd a hidden bonus-t):

http://blog.zpao.com/post/1140456188/cascaded-session-restore-a-hidden-…

Nekem sajnos az a szokásom, hogy nyitva hagyok sok-sok tab-ot. Így az indulás rém lassú volt, amíg meg nem találtam a fentit. Így most 139 tab van nyitva (tudom, más is mondta, hogy erre vannak a könyvjelzők...), de egyszerre csak egyet tölt be, így a memória fogyasztás kicsi és az indítás is villámgyors. És nem kell felhagynom a rossz szokásommal :D

( Sanya v | 2011. 08. 13., szo – 07:15 )

van 16GB memória a laptopomban, szvsz még nem volt tele 1x sem (olcsó volt a ram, amiatt vettem tele a gépet)

( uid_18247 | 2011. 08. 13., szo – 17:58 )

szábszkrájb
------------------------------------
A Windowsról sokat elárul, hogy Slackwaret könnyebb telepíteni.