WNZ: Hemmeligt facelift til iPad 2WNZ: Apple overvejede fysisk tastatur til iPhone
Diablo III's Real-Money AH rykkes til "soon"-tidsramme på grund af lanceringsproblemerSquare Enix: Activision må være tossede for at droppe True Crime: Hong KongAnalytiker: Grand Theft Auto 5 sælger mindst 14 millioner eksemplarerMinecraft rammer 9 millioner solgte eksemplarerNy, lang gameplay-trailer til Sleeping DogsNy gameplay-video fra Sniper: Ghost Warrior 2 tager os til BosnienJapansk lanceringstrailer til Anarchy ReignsResident Evil: Chronicles HD får dato og prisHvornår har du sidst været til LAN?
21. sep. 2009 07:38Det er ikke længe siden, at Google udgav Chrome 3, der, som det er standard ved den slags udgivelser, introducerer en række nye funktioner og forbedringer.
En af forbedringerne er højere hastighed ved brug af JavaScript, der i forhold til Chrome 2 steg med 25 %, men hastighedsstigningen kunne have været højere.
Ifølge hjemmesiden Betanews var den seneste beta-udgave af Chrome 3 hurtigere end den endelige udgave. I en test udviklet af Betanews, der efterligner virkelige forhold mest muligt, er Chrome 3 6,5 % langsommere end betaen.
Til trods for den mindre hastighed er Chrome 3 stadig den hurtigste browser til JavaScript på markedet med en score på 18,68 point i Betanews' test, tæt efterfulgt af Safari 4 med 16,57 point.
21. sep. 2009 08:06
Ok og hvor i alverden ved Betanews fra, at der ikke skulle ske ændring fra beta til final, hvor bivirkningen var en langsommere javascript afvikling? - Så jeg ved ikke om hastigheden kunne have været højre, de har jo nok ikke gjort den langsommmere 'bare fordi'.
21. sep. 2009 09:16
Venter meget på, at AdBlock Plus bliver tilgængeligt til Chrome!
Intel Core 2 Quad Q9450 2,66ghz 12mb l2 1333 fsb, 4gb ddr3 1333mhz, nForce790i Ultra.
21. sep. 2009 09:34
Prøv fx. at besøge en hjemmeside som eb.dk med IE. Det er en dræber hvis man ikke har en rimelig kraftig maskine (eb er nok også selv skyld i en del slamkodning).
Personligt laver jeg også hjemmesider som let består at flere hundrede kb javascript der i særdeleshed bruges til dom-manipulering. Der kan jeg også mærke meget stor forskel på afviklingshastigheden i de forskellige browsere (uden at det dog når eb-niveauet).
I like HTC Android phones. Everything else is non-sense
21. sep. 2009 10:45
#4
Prøv at kig på jQuery til DOM. Det er meget mere kompakt og intuitivt. Hvis du allerede bruger jQuery og har flere 100KB til DOM manipulering - ja, så er jeg imponeret :O
21. sep. 2009 11:10
De gør vel bare ligesom Usain Bolt...
Der er ikke nogen grund til at give sig fuldt ud med det samme. Så er det bedre at få den omtale det giver i næste version hvor hastighed jo igen vil værre hurtigere
21. sep. 2009 11:33
Jeg gætter på, at der under beta testen blev fundet en fejl, der skulle rettes.
Jeg kan forestille mig to mulige forklaringer på, hvorfor det betød at den blev lidt langsommere.
Enten er det simpelthen fordi et sted i koden manglede at tage højde for en situation, og et check for den situation hver gang man kommer derigennem tager lidt længere tid, og en version uden fejlen, er dermed langsommere.
Eller også har de ikke fundet fejlen endnu, og har derfor valgt at bruge en ældre version af den del af koden. Og den ældre del har været langsommere.
Udviklerne er sikkert klar over, at der er noget, der kan gøres endnu hurtigere. Så mon ikke næste version vil have en optimeret udgave.
Så de har nok stået med valget imellem at udgive en final, der var lidt langsommere end beta versionen, eller at vente måske en uge, måske en måned. Men hvis den allerede er hurtigere end den foregående ikke-beta version, så er hastigheden jo ikke et argument for at vente.
21. sep. 2009 11:38
#5
Det er ikke kun dom-manipulering, men også datahåndtering.
Jeg bruger nogle gange jQuery afhængigt af projektet, men det kan jo kun bruges til visse ting. Det kan bare hjælpe med nogle af kaldene, men de skal jo stadig udføres.
Da jQuery i sig selv tilføjer over 50kb, så er det tit begrænset hvad den samlede databesparelse løber op i.
Det er langt fra alt man kan bruge jQuery til, så på et projekt med fx. 250kb js, kan jQuery måske spare mig for ialt 20-30kb. Det er ofte mere udviklingstiden der kan spares på.
I like HTC Android phones. Everything else is non-sense
21. sep. 2009 13:03
Jeg synes kun folk tester hastigheden af javascsript efterhånden. Det forekommer lidt ensidigt.
21. sep. 2009 19:26
Jeg synes kun folk tester hastigheden af javascsript efterhånden. Det forekommer lidt ensidigt.knasknaz (#9)
Hvad skulle man som browser producent ellers gå op i?
21. sep. 2009 19:46
code insight... they only changed sleep(200) to sleep(220) ;)Saxov (#2)
Der findes ikke sleep i javascript.
EDIT: - OK. Jeg forstår hvad du mener.
Jeg har fix'et flere javascripts specielt til Chrome.
Den kan fx. afvikle et javascriptet inden en sides indhold er læst helt ind. Hvor andre brovsere er så langsomme, at der ikke er taget højde for dette potientielle problem.
Måske har det også noget at gøre med hvor mange tråde der bruges til at vise en side.
21. sep. 2009 19:53
Hvad skulle man som browser producent ellers gå op i?ismetteren (#10)
Rendering?
Men nu benytter Chrome jo WebKit, så Google står ikke direkte selv for optimeringer af hastigheden der.
Hvis i hører om forbedringer i Safari, kommer de nok også til Chrome :)
http://about.me/windcape
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.
