mboost-dp1
firefox, ppc og pol.dk
Siden politiken.dk for nyligt redesignede/opdaterede deres side har firefox brugt alt tilgængelig cpu-kraft så snart pol.dk var åben.
Det er ikke en under-proces der sluger kræfterne, men firefox-bin.
Nogen der har et bud på hvad problemet er???
Jeg kører firefox 1.5.0.3 på kde 3.5.2 på gentoo på ppc (puha).
Jeg har netop opdateret mit system men problemet var der også med ff-1.5.0.2 på kde-3.4.3 :(
Det er ikke en under-proces der sluger kræfterne, men firefox-bin.
Nogen der har et bud på hvad problemet er???
Jeg kører firefox 1.5.0.3 på kde 3.5.2 på gentoo på ppc (puha).
Jeg har netop opdateret mit system men problemet var der også med ff-1.5.0.2 på kde-3.4.3 :(
hos mig æder den konstant 30-40%.
Jeg er på en 1.5.0.2 på WinXP SP1, Pentium M bærbar.
Det er da skummelt at den æder så meget :o
Jeg er på en 1.5.0.2 på WinXP SP1, Pentium M bærbar.
Det er da skummelt at den æder så meget :o
ok, da min cpu kun er en 1ghz g4 så er det nok derfor den æder hvad der føles som det hele :D
men hvad f.... har de lavet med siden
men hvad f.... har de lavet med siden
Jeg bruger 1.5.0.3 på WinXP SP2 med en AMD Athlon64 3800+. Én tab (og intet andet) med Politiken.dk hæver CPU-forbrug fra 0 til ca. 5-10%, vel at mærke også efter den er loadet helt færdig. 12 tabs fra samme side får forbruget helt op på ca. 60%, og sløver markant andre processer. Der er ugler i mosen...
1. Der er en grund til at Firefox 1.0.8 er nyeste stable i Gentoo. Firefox 1.5.x er smækfyldt med bugs..
2. Hvis man indsætter pol.dk i en validator får man ganske horrible resultater. Fantastisk det skal være så svært.
2. Hvis man indsætter pol.dk i en validator får man ganske horrible resultater. Fantastisk det skal være så svært.
#6 den står så som stable på ppc platformen
http://packages.gentoo.org/search/?sstring=firefox
på x86 har du ret. Men det tyder på fejlen/buggen ligger et andet sted
http://packages.gentoo.org/search/?sstring=firefox
på x86 har du ret. Men det tyder på fejlen/buggen ligger et andet sted
well nu blev jeg nysgerrig, og kan nu fortælle at det er politikens UR der laver problemet. så hvis der er en af jer flinke rare gutter som fatter java-script, der gider at tjekke om det er FF der har et problem, eller om det er politiken´s webprogramør der skal have slag med en våd søndagsberlinger.
her er koden som jeg slettede i HTML-filen.
//Dynamisk tid efter dato på Politikens top
function Ur_top ()
{
tid = new Date();
tt = tid.getHours();
mm = tid.getMinutes();
ss = tid.getSeconds();
if (tt<10)
tt="0" + tt;
if (mm<10)
mm="0" + mm;
if(ss<10)
ss="0" + ss;
document.getElementById("urfelt").innerHTML= " kl. " + tt + ":" + mm;
setTimeout("Ur_top();",1000);
}
<!-- JavaScript {END} -->
</script>
her er koden som jeg slettede i HTML-filen.
//Dynamisk tid efter dato på Politikens top
function Ur_top ()
{
tid = new Date();
tt = tid.getHours();
mm = tid.getMinutes();
ss = tid.getSeconds();
if (tt<10)
tt="0" + tt;
if (mm<10)
mm="0" + mm;
if(ss<10)
ss="0" + ss;
document.getElementById("urfelt").innerHTML= " kl. " + tt + ":" + mm;
setTimeout("Ur_top();",1000);
}
<!-- JavaScript {END} -->
</script>
#9 nightH:
Jeg oplever intet øget ressourceforbrug med Windows XP fuldt opdateret og den seneste Firefox.
Der er dog en fejl i den JavaScript-kode, som du indsætter, men jeg tvivler på, at det er grunden til problemet. Man bør aldrig afslutte en <script>-blok med en kommentar* (<!-- -->), og det kan jo være, at Firefox prøver at tolke det som en udregning.
*) Man kan bruge en kommentar ind i hele <script>-blokken, men det forudsætter, at man foran --> placerer en JavaScript-kommentering (//).
Derudover er det da ret dårligt kodet, når man kalder funktionen hvert sekund, men kun viser uret med angivelse af timer og minutter.
Jeg oplever intet øget ressourceforbrug med Windows XP fuldt opdateret og den seneste Firefox.
Der er dog en fejl i den JavaScript-kode, som du indsætter, men jeg tvivler på, at det er grunden til problemet. Man bør aldrig afslutte en <script>-blok med en kommentar* (<!-- -->), og det kan jo være, at Firefox prøver at tolke det som en udregning.
*) Man kan bruge en kommentar ind i hele <script>-blokken, men det forudsætter, at man foran --> placerer en JavaScript-kommentering (//).
Derudover er det da ret dårligt kodet, når man kalder funktionen hvert sekund, men kun viser uret med angivelse af timer og minutter.
@ 10 lyder ellers som om det kunne være der.. den sluger lige 30 % af mine ressourcer.
anyways det er der problemet ligger og jeg har ved hjælp af et greasemonkey script løst problemet.
uploader det lige.
anyways det er der problemet ligger og jeg har ved hjælp af et greasemonkey script løst problemet.
uploader det lige.
#10 hmm, jeg sidder på en en windows 2000 og java Version 1.5.0 (build 1.5.0_06-b05), hvilken java bruger du ?
bruger FF 1.5.0.3
heh, har lige afprøvet din ide, det var ikke det, men "fejlen" ligger i denne linje:
setTimeout("Ur_top();",1000);
hos mig bruger FF konstant 22-23 procent CPU med denne værdi, hvis jeg ændrer den til 2500, så står den og skifter mellem 0 og op til 20, og hvis jeg sætter den til 7500 så laver den et spring fra 0 til 20, ca. hvert 5 sekund.
det passer vel fint med at det er deres javascript som kører for tit, eftersom de aligevel ikke opdaterer sekunderne på siden.
bruger FF 1.5.0.3
heh, har lige afprøvet din ide, det var ikke det, men "fejlen" ligger i denne linje:
setTimeout("Ur_top();",1000);
hos mig bruger FF konstant 22-23 procent CPU med denne værdi, hvis jeg ændrer den til 2500, så står den og skifter mellem 0 og op til 20, og hvis jeg sætter den til 7500 så laver den et spring fra 0 til 20, ca. hvert 5 sekund.
det passer vel fint med at det er deres javascript som kører for tit, eftersom de aligevel ikke opdaterer sekunderne på siden.
http://www.uploadtemple.com/view.php/1147598176.tx... her er min løsning, ingen anelse på hvordan scriptet skal loades
ellers brugte jeg http://platypus.mozdev.org/
og greasemonkey extensions i firefox til at udbedre problemet.. ved blot at slette time/minutter uret der kommer efter datoen øverst til venstre på siden. håber det hjalp, er der en som har kontaktet webmasteren og evt henvist ham til denne debat?
ellers brugte jeg http://platypus.mozdev.org/
og greasemonkey extensions i firefox til at udbedre problemet.. ved blot at slette time/minutter uret der kommer efter datoen øverst til venstre på siden. håber det hjalp, er der en som har kontaktet webmasteren og evt henvist ham til denne debat?
#12 nightH:
Jeg synes dog egentlig, at det virker ret underligt, at Firefox kan sluge så mange ressourcer blot ved at hive tiden ud hvert eneste sekund. Det tyder på en kæmpe designfejl et sted.
Jeg kunne til dels forstå, hvis funktionen blev afviklet hvert eneste millisekund, men det er godt nok en fejl, hvis et så simpel JavaScript kan bruge så mange ressourcer blot ved opdatering hvert sekund.
Alternativt så skal I til at opgradere jeres CPU'er :-)
Jeg synes dog egentlig, at det virker ret underligt, at Firefox kan sluge så mange ressourcer blot ved at hive tiden ud hvert eneste sekund. Det tyder på en kæmpe designfejl et sted.
Jeg kunne til dels forstå, hvis funktionen blev afviklet hvert eneste millisekund, men det er godt nok en fejl, hvis et så simpel JavaScript kan bruge så mange ressourcer blot ved opdatering hvert sekund.
Alternativt så skal I til at opgradere jeres CPU'er :-)
Ressourceforbruget skyldes rigtigt nok at uret opdaterer hvert sekund, men det er ikke udregningen af klokkeslæt der er problemet.
Sagen er den at Firefox (ligesom andre browsere) rendererer hele siden forfra hver gang der bliver ændret i HTML kilden. Det vil sige at den hvert sekund læser HTML og CSS forfra for at tegne det billede du ser på din skærm.
Hvis du sætter din ressourcemåler til at opdatere lidt oftere end hvert sekund (hvilket vist plejer at være standard) vil du se at Firefox ikke konstant bruger CPU, men kun i en kort periode hver gang siden rendereres forfra.
Indlysende nok tager det længere tid at renderere en side med meget indhold, dvs. f.eks. Politikens forside.
Derfor er det temmeligt dumt at køre et script der ændrer HTML koden hvert sekund, især fordi uret alligevel kun viser timer og minutter.
Som svar til #9 vil jeg sige at det nok vil være synd at smække Politikens webdesigner med en våd Berlinger da han nok ikke har vidst bedre.
Der er desværre en udpræget mangel på kompetence hos de fleste webudviklere nu om dage, så at lade det hele gå ud over en enkelt koder hos Politiken er nok ikke helt fair.
Sagen er den at Firefox (ligesom andre browsere) rendererer hele siden forfra hver gang der bliver ændret i HTML kilden. Det vil sige at den hvert sekund læser HTML og CSS forfra for at tegne det billede du ser på din skærm.
Hvis du sætter din ressourcemåler til at opdatere lidt oftere end hvert sekund (hvilket vist plejer at være standard) vil du se at Firefox ikke konstant bruger CPU, men kun i en kort periode hver gang siden rendereres forfra.
Indlysende nok tager det længere tid at renderere en side med meget indhold, dvs. f.eks. Politikens forside.
Derfor er det temmeligt dumt at køre et script der ændrer HTML koden hvert sekund, især fordi uret alligevel kun viser timer og minutter.
Som svar til #9 vil jeg sige at det nok vil være synd at smække Politikens webdesigner med en våd Berlinger da han nok ikke har vidst bedre.
Der er desværre en udpræget mangel på kompetence hos de fleste webudviklere nu om dage, så at lade det hele gå ud over en enkelt koder hos Politiken er nok ikke helt fair.
nightH og Acro fandt problemet, jeg lavede en hurtig workaround og nu kan jeg vidst ikke deltage mere med min viden.
Men det bedste i kan gøre nu er at finde en gennemgående løsning, evt en ændring i koden der siger til FF at den ikke skal refreshe.
og derefter rapportere til mozilla med løsningen i scriptform, og fortælle hvad der skaber problemet.
Kage Out :P
Men det bedste i kan gøre nu er at finde en gennemgående løsning, evt en ændring i koden der siger til FF at den ikke skal refreshe.
og derefter rapportere til mozilla med løsningen i scriptform, og fortælle hvad der skaber problemet.
Kage Out :P
#17 yosh:
Problemet er jo netop, at der IKKE bliver ændret i kilden, og det burde Firefox være intelligent nok til at opdage. Det er jo bare at checke, hvorvidt den nye værdi er forskellig fra den gamle, da det vil fjerne det store ressourceforbrug.
Selvfølgelig kan man sige, at det ikke burde være nødvendigt, men det er alligevel sådan en ting, som man bør gøre anvendelse af for at sikre en god oplevelse over for brugeren (korrekt JavaScript, HTML og andet er jo ikke ligefrem standard, desværre).
Problemet er jo netop, at der IKKE bliver ændret i kilden, og det burde Firefox være intelligent nok til at opdage. Det er jo bare at checke, hvorvidt den nye værdi er forskellig fra den gamle, da det vil fjerne det store ressourceforbrug.
Selvfølgelig kan man sige, at det ikke burde være nødvendigt, men det er alligevel sådan en ting, som man bør gøre anvendelse af for at sikre en god oplevelse over for brugeren (korrekt JavaScript, HTML og andet er jo ikke ligefrem standard, desværre).
#18 HashKagen:
Lad mig lige understrege at der IKKE er tale om en Firefox bug. Et ressourceforbrug som det du ser her er klart at forvente når et script tvinger en så stor side til at renderere forfra.
#19 Acro:
I det øjeblik du ændrer innerHTML strengen på et hvilket som helst element i dokumentet bliver det betragtet som en ændring i kilden. Sådan er det bare og det er der ikke noget at gøre ved.
Der findes dog teknikker til at undgå at hele siden bliver rendereret forfra. Det kræver blot en smule indsigt i hvordan CSS fungerer i browseren.
I dette tilfælde kan webdesigneren f.eks. placere det element der indeholder tidsstemplet i et lag for sig ved at sætte CSS egenskaben position til absolute.
På den måde vil elementet blive rendereret uafhængigt af resten af siden, lige som visse andre elementer som iframes og form inputs.
Det vil sige at hvis vi et øjeblik glemmer alt om pæn kode og fjerner følgende stykke HTML:
<span id="urfelt"></span>
Til fordel for at indsætte følgende i f.eks. toppen af dokumentet:
<div id="urfelt" style="position: absolute; top: 37px; left: 106px; color: #FFF; font: bold 11px Verdana;"></div>
Vil vi løse problemet med det store ressourceforbrug fordi browseren nu kun vil renderere et enkelt div element forfra, i stedet for hele siden.
Lad mig lige understrege at der IKKE er tale om en Firefox bug. Et ressourceforbrug som det du ser her er klart at forvente når et script tvinger en så stor side til at renderere forfra.
#19 Acro:
I det øjeblik du ændrer innerHTML strengen på et hvilket som helst element i dokumentet bliver det betragtet som en ændring i kilden. Sådan er det bare og det er der ikke noget at gøre ved.
Der findes dog teknikker til at undgå at hele siden bliver rendereret forfra. Det kræver blot en smule indsigt i hvordan CSS fungerer i browseren.
I dette tilfælde kan webdesigneren f.eks. placere det element der indeholder tidsstemplet i et lag for sig ved at sætte CSS egenskaben position til absolute.
På den måde vil elementet blive rendereret uafhængigt af resten af siden, lige som visse andre elementer som iframes og form inputs.
Det vil sige at hvis vi et øjeblik glemmer alt om pæn kode og fjerner følgende stykke HTML:
<span id="urfelt"></span>
Til fordel for at indsætte følgende i f.eks. toppen af dokumentet:
<div id="urfelt" style="position: absolute; top: 37px; left: 106px; color: #FFF; font: bold 11px Verdana;"></div>
Vil vi løse problemet med det store ressourceforbrug fordi browseren nu kun vil renderere et enkelt div element forfra, i stedet for hele siden.
jeg har kontaktet mozilla, i fremtiden kan det jo være at browseren selv vil kunne opfatte fejlen.
er der ikke én af jer kloge hoveder der kan kontakte webmasteren og få ham til at fixe dette?
er der ikke én af jer kloge hoveder der kan kontakte webmasteren og få ham til at fixe dette?
#20 yosh:
Browseren kan sagtens indeholde en teknik, der ser på, hvorvidt der faktisk ændres noget og kun renderer i sådanne tilfælde. Kilden bliver jo reelt set ikke ændret, når man ændrer noget til en værdi, det allerede har, og det burde browseren være i stand til at skelne imellem.
Ideelt set, så er det ikke Mozillas opgave, men hvis Firefox kører ustabilt, så tænker de fleste brugere ikke, at det er Politikens webansvarlige, der er i stand til at udbedre fejlen. De fleste bemærker, at Firefox kører dårligt.
Browseren kan sagtens indeholde en teknik, der ser på, hvorvidt der faktisk ændres noget og kun renderer i sådanne tilfælde. Kilden bliver jo reelt set ikke ændret, når man ændrer noget til en værdi, det allerede har, og det burde browseren være i stand til at skelne imellem.
Ideelt set, så er det ikke Mozillas opgave, men hvis Firefox kører ustabilt, så tænker de fleste brugere ikke, at det er Politikens webansvarlige, der er i stand til at udbedre fejlen. De fleste bemærker, at Firefox kører dårligt.
#21 HashKagen:
Jeg prøver lige igen: Der er IKKE tale om en fejl, så lad være med at plage Mozilla teamet med det her.
Hvis du synes det er så vigtigt at få det her klaret kan du jo selv kontakte Politikens internetavis og se om de gider gøre noget ved det. Det er jo deres ansvar at deres website fungerer som det skal.
Jeg prøver lige igen: Der er IKKE tale om en fejl, så lad være med at plage Mozilla teamet med det her.
Hvis du synes det er så vigtigt at få det her klaret kan du jo selv kontakte Politikens internetavis og se om de gider gøre noget ved det. Det er jo deres ansvar at deres website fungerer som det skal.
@#15: bøh, så Java har intet med JavaScript at gøre? tja det viser jo med al tydelighed bare min manglende viden på området, selvom det ikke helt passer svjv, da du skal bruge java til at fortolke javascript, eller er der noget jeg helt har misforstået? (jeg bragte kun java ind i diskutionen fordi hvis der evt var en fejl i en specifik udgave af java, kunne det forklare hvorfor et javascript blev fejlfortolket)
anyway, så er jeg ganske enig mht at der skal tages kontakt til webmasteren på pol, jeg har bare ikke tid nu, så håber en anden gør det, og husk at gøre det på en sober måde.
anyway, så er jeg ganske enig mht at der skal tages kontakt til webmasteren på pol, jeg har bare ikke tid nu, så håber en anden gør det, og husk at gøre det på en sober måde.
#25
"@#15: bøh, så Java har intet med JavaScript at gøre?"
Ikke andet end at syntaksen minder om hinanden (og om alle andre objektorienterede sprog med C-agtig syntaks)
"tja det viser jo med al tydelighed bare min manglende viden på området, selvom det ikke helt passer svjv, da du skal bruge java til at fortolke javascript, eller er der noget jeg helt har misforstået?"
Ja det er noget du har misforstået. Javascript er noget som browseren i sig selv fortolker, og er et scriptsprog til at udføre diverse operationer på nogle foruddefinerede objekter som browseren stiller til rådighed (selve winduet, websiden, billederne, dvs, forms osv. er objekter).
Java er derimod et sprog for sig selv, som skal køres igennem en virtual machine (java runtime environment), som skaber en oversættelse fra java's bytecode og til den processorarkitektur det udføres på.
De 2 ting har intet med hinanden at gøre, og windows XP som ikke kommer med nogen java virtual machine installeret, kan sagtens køre javasript out of box...
Edit:
#26 har du nogensinde set en javacript-fortolker skrevet i java? (ud over nogen der har lavet et eller andet pseudo-projekt med en java browser)?
"@#15: bøh, så Java har intet med JavaScript at gøre?"
Ikke andet end at syntaksen minder om hinanden (og om alle andre objektorienterede sprog med C-agtig syntaks)
"tja det viser jo med al tydelighed bare min manglende viden på området, selvom det ikke helt passer svjv, da du skal bruge java til at fortolke javascript, eller er der noget jeg helt har misforstået?"
Ja det er noget du har misforstået. Javascript er noget som browseren i sig selv fortolker, og er et scriptsprog til at udføre diverse operationer på nogle foruddefinerede objekter som browseren stiller til rådighed (selve winduet, websiden, billederne, dvs, forms osv. er objekter).
Java er derimod et sprog for sig selv, som skal køres igennem en virtual machine (java runtime environment), som skaber en oversættelse fra java's bytecode og til den processorarkitektur det udføres på.
De 2 ting har intet med hinanden at gøre, og windows XP som ikke kommer med nogen java virtual machine installeret, kan sagtens køre javasript out of box...
Edit:
#26 har du nogensinde set en javacript-fortolker skrevet i java? (ud over nogen der har lavet et eller andet pseudo-projekt med en java browser)?
jeg nævnte også for dem at det ikke var en fejl med selve browseren, nærmere en request for at den automatisk vil opfatte problemet og lade være med at spilde resourcer.
@26+27: jamen så blev jeg det klogere, altid rart at blive lidt klogere på de ting man ikke beskæftiger sig med inden for IT.
og nu hvor amokk er kommet med en fin udredning, så vidste jeg faktisk godt det med java, havde bare ikke tænkt nærmere over det :/
#29: det mener jeg så også er den rette måde at komunikere det på, altså som en feature-request.
edit:
har forøvrigt glemt at takke for den gode forklaring i #20
og nu hvor amokk er kommet med en fin udredning, så vidste jeg faktisk godt det med java, havde bare ikke tænkt nærmere over det :/
#29: det mener jeg så også er den rette måde at komunikere det på, altså som en feature-request.
edit:
har forøvrigt glemt at takke for den gode forklaring i #20
jah det er sku altid interessant at løse sådanne problemer, men skal læse lidt mere om javascript osv før jeg kan hjælpe ordentligt. ;)
hygge...
hygge...
pol.dk ser lige nu ud til at fungere 'normalt' igen :)
Hvis en af jer mere web-kyndige har haft kontakt med dem,
så tak herfra.
Hvis en af jer mere web-kyndige har haft kontakt med dem,
så tak herfra.
@#32: hmm "fungere 'normalt' igen" tja det er som man ser det, det man har gjort er at sætte tiden op, så siden refresher 1 gang i minuttet, istedet for 1 gang i sekundet, men alt hvordan man ser det, så er "problmet" der stadig (altså hvis man anser det for en fejl at refreshe hele siden) for man kunne faktisk godt forsvare det lidt med at det er en nyhedssite, så der er mening med at opdatere siden ofte. men så vidt jeg kan forstå på de personer som har medvirket i denne tråd, og som har forstand på hjemmesider, så er det stadig ikke den "korrekte" måde at lave tingene på. (#17 giver en god forklaring på dette).
#33 Der er forskel på at "refreshe" sidens indhold (altså hente siden fra serveren igen), og så at rendere den forfra grafisk... Det som sker er jo at urets opdatering ændre på sidens HTML kode og derfor skal siden renderes forfra, og det kan jo lige så godt gøres en gang i minuttet når uret kun viser timer og minutter...
De ressourcer det så vil kræve er jo ikke noget nævneværdigt... Forresten fatter jeg ikke ideen med et ur som viser brugerens lokale tid i browseren, alle moderne desktop systemer viser jo uret på skærmen... Så medmindre det er binært er det uden mening...
De ressourcer det så vil kræve er jo ikke noget nævneværdigt... Forresten fatter jeg ikke ideen med et ur som viser brugerens lokale tid i browseren, alle moderne desktop systemer viser jo uret på skærmen... Så medmindre det er binært er det uden mening...
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Support
Gå til bund