Kinyitottam a
htop-ot, rászűrtem a palemoon binárisra, sorrendeztem CPU használat alapján, majd kinyitottam a PaleMoon release notes-t a 29.4.6-ossal is, meg 31.1.0-ással is. Mind a két PaleMoon egy tonna process-t forkol, viszont amíg a 29-es scrollozás közben egy processen produkál kb. 10-15%-os terhelést és egy másikon kb. 0.7-2.0%-os terhelést, addig a 31-es egy processen csinál 70-75%-osat, egy másikon 62-63%-osat és egy harmadikon 0.7-1.4%-osat. Ezek a folyamatos terhelések, amik a scrollozás alatt mérhetőek, nem üresjáratban. ~17% vs. ~140% terhelés egy hótt egyszerű - JS-mentes - oldal scrollozásánál.
Ugyan elsőre felírtam modern korunk szoftverfejlesztésének listájára ezt is, de aztán elgondolkoztam, hogy nem valami beállítás csinálja ezt, pl. a hw-gyorsítás környékén? Csak mert a release notes-ban azt írták, hogy "Fixed an important stability and performance issue related to hardware acceleration."
Akkor about:config kinyit, search bubble-be "acceleration" bepötyög. Többek közt volt egy olyan beállítás is, hogy layers.acceleration.enabled, ami a hw-accel bekapcsolásáért felel Az Internet szerint és ami eddig hamisra volt állítva. (Hogy miért nem engedélyezett ez alapból, azt nem tudom, de ennek ellenére eddig a browser éppenhogy gyorsabb és kevésbé éhesebb volt nélküle.) Átállítottam igazra, majd újraindítottam a browsert és újra mértem. Ezúttal egy process csinált 12-18%-os terhelést, egy másik 2-6%-ost (de 6-ig csak ritkán ugrott ki, amúgy 2.0 és 3.3 között ingázott), egy harmadik meg 0.7-2.0%-ost. Ez így máris csak ~25%-os worst-case terhelés és kb. átlag 15-20%-os, ami máris elfogadható az előző verzió 17%-os worst-case terheléséhez és 10-15%-os átlagához képest. Illetve legyünk korrektek: ha a hw-accel be van kapcsolva, akkor a 29-es is nagyjából ugyanazokat a számokat hozza, mint a 31-es, viszont amíg a 29-esben a kikapcsolása kb. 5%-os terheléscsökkenést jelent, addig a 31-esben közel hétszeres terhelésnövekedést.
Hogy a 29-es miért terhelte kevésbé a gépet hw-accel nélkül, mint vele, azt nem tudom, ill. azt sem, hogy ha eddig ez így volt, akkor a 31-es meg miért bőgeti a ventilátorokat nélküle...de legalább megoldódott a terhelés kérdése és így végre tényleg megint lehet használni a legacy Firefox addonokat.- TCH blogja
- A hozzászóláshoz be kell jelentkezni
- 157 megtekintés
Hozzászólások
Jó, hogy van, de sose próbáltam, kíváncsi vagyok mennyien használhatják. Nagyon régen chrome-ra váltottam (azon belül meg már egy ideje Vivaldi), néha indítok Firefox-ot, de kényelmetlen, vagy valahogy nem adja. Lassú, talán az a legnagyobb problémám. Majd megnézem mit tudnak a forkok, ha lesz időm, hangulatom egy időben :) Sajnálom egyébként, hogy ide jutott a Firefox, de sokat tettek érte maguk is. Emlékszem régen mindig néztem, hogy na nemsoká lenyomja az internet explorert, aztán meg hirtelen a chrome elverte mindkettőt. Kéne egy reboot megint náluk, de szerintem már nincs is aki meg tudná csinálni... Akik maradtak szerintem már csak felsöprik a morzsát, amit azért szórnak, hogy maradjon alternatíva a böngésző piacon. Jól el is vannak ezzel...
- A hozzászóláshoz be kell jelentkezni
Ez se lesz egy sebességbajnok egy krómhoz képest, de ennek nem is az a lényege, hanem az, hogy ezzel még mennek a régi rókás kiegészítők.
A róka kudarcáról csak saját maguk tehetnek. Az egy dolog, hogy a króm sikeresebben szipkázta el az exploder felhasználóit, mint ők, de azt, hogy a króm az ő ~30%-os (usque 2 milliárd júzeres) felhasználótáborukat is el tudta szipkázni, azt csak maguknak köszönhetik, mert elkezdték lemásolni a krómot. A krómnak egyetlen egy plusz tulajdonsága volt a rókával szemben: a JS VM sebessége, de nem olyan értelemben, hogy a rókáé annyira lassú lett volna, csak lassabb, mint a krómé. Aki rókajúzer volt, az ezt simán megbocsátotta a rókának. A króm másolásával együtt járó lebutítással parallel bloatosodást, a júzerek hülyének nézését, a privacy issue-kat, a pofátlanságokat viszont nem lehetett megbocsátani.
- A hozzászóláshoz be kell jelentkezni