JS Native performance på strenge (find karakter)

[Rune Jensen]

Jeg stødte tilfældigvis på denne testside, som kan vise performance af
forskellige stykker JS kode.

Jeg lavede en lille tilføjelse til en allerede eksisterende test, for
at se, hvad der var hurtigst, hvis man skal finde en bestemt karakter
i en streng, slicing, charAt eller a[].

Slicing af en streng er langsomst, mens indexet af en streng lader til
at være gennemgående hurtigst (havde jeg nu også på fornemmelsen). Så
hvis man kender længden af strengen i forvejen, kan den være bedst.

Hvis nogen gider teste i IE9+10, ville det være rart.

http://jsperf.com/string-charat-vs-slice/2

Det er meget nemt at lave disse tests selv, og de ser også ud til at
være pålidelige så vidt jeg kan dømme.

Vær opmærksom på, at der testes relativt, og man derfor ikke kan
direkte sammenligne imellem browsere, da systemet de kører på, ikke er
oplyst.

MVH
Rune Jensen

[Jens Peter Karlsen]

IE10 Windows 8 64.
Som forventet var slice langt det langsomste.
CharAt var en ubetydelighed hurtigere end index.

Regards Jens Peter Karlsen.

On Sun, 24 Mar 2013 03:19:40 -0700 (PDT), Rune Jensen

Post by Rune Jensen
Hvis nogen gider teste i IE9+10, ville det være rart.
http://jsperf.com/string-charat-vs-slice/2

[r***@hotmail.com]

Post by Jens Peter Karlsen
IE10 Windows 8 64.
Som forventet var slice langt det langsomste.
CharAt var en ubetydelighed hurtigere end index.

Nå... så er det vidst ret lige meget, om man bruger index eller
charAt, når browserne er så uenige alligevel.

Firefox siger nemlig det samme som IE... men Chrome er omvendt.

Mange tak for indsatsen, jeg blev i hvert fald klogere.

Eftersom charAt og index er nogenlunde generelt lige optimeret, tror
jeg, jeg vil foretrække charAt, så man undgår out of bound.

Jeg vil lige sige, det kan altså også bruges til mindre nørdede ting
end det her, og det skal ikke være det nørdede, som gør man ikke vil
bruge siden. Det er det, jeg synes er så smart ved den side, man kan
teste simpelthen alt... Har du to funktioner, som laver det samme, og
vil vide, hvilken er hurtigst, så er det hammer nemt lige at smide ind
og teste det.


MVH
Rune Jensen

[Birger Sørensen]

Post by Rune Jensen
Jeg stødte tilfældigvis på denne testside, som kan vise performance af
forskellige stykker JS kode.
Jeg lavede en lille tilføjelse til en allerede eksisterende test, for
at se, hvad der var hurtigst, hvis man skal finde en bestemt karakter
i en streng, slicing, charAt eller a[].
Slicing af en streng er langsomst, mens indexet af en streng lader til
at være gennemgående hurtigst (havde jeg nu også på fornemmelsen). Så
hvis man kender længden af strengen i forvejen, kan den være bedst.
Hvis nogen gider teste i IE9+10, ville det være rart.
http://jsperf.com/string-charat-vs-slice/2
Det er meget nemt at lave disse tests selv, og de ser også ud til at
være pålidelige så vidt jeg kan dømme.
Vær opmærksom på, at der testes relativt, og man derfor ikke kan
direkte sammenligne imellem browsere, da systemet de kører på, ikke er
oplyst.
MVH
Rune Jensen

Der er en version 3 også - det fremgår ikke hvad forskellen er.
Resultaterne bekræfter graferne på siden.

Lettere forvirret.
JS kører på brugerens PC, og resultaterne (opgives i
operationer/sekund) vil derfor være afhængige af ikke kun browseren,
men også PC'ens CPU, hastighed og hvad der ellers foregår på PC'en.
Med mindre der er tale om afvikling på serveren - hvor det svjks
foregår i IE10 alt sammen. Så er forskellene et udtryk for den
besøgendes forbindelse, og har ikke så meget med browseren at gøre. Og
hvad er så formålet?

Birger

[r***@hotmail.com]

Jeg st dte tilf ldigvis p denne testside, som kan vise performance af
forskellige stykker JS kode.
Jeg lavede en lille tilf jelse til en allerede eksisterende test, for
at se, hvad der var hurtigst, hvis man skal finde en bestemt karakter
i en streng, slicing, charAt eller a[].
Slicing af en streng er langsomst, mens indexet af en streng lader til
at v re gennemg ende hurtigst (havde jeg nu ogs p fornemmelsen). S
hvis man kender l ngden af strengen i forvejen, kan den v re bedst.
Hvis nogen gider teste i IE9+10, ville det v re rart.
http://jsperf.com/string-charat-vs-slice/2
Det er meget nemt at lave disse tests selv, og de ser ogs ud til at
v re p lidelige s vidt jeg kan d mme.
V r opm rksom p , at der testes relativt, og man derfor ikke kan
direkte sammenligne imellem browsere, da systemet de k rer p , ikke er
oplyst.
MVH
Rune Jensen

Der er en version 3 ogs - det fremg r ikke hvad forskellen er.
Resultaterne bekræfter graferne p siden.

Det var mig, som reviderede i version3 også... jeg indsatte en ; som
jeg har lært her, man skal gøre :)

Lettere forvirret.
JS k rer p brugerens PC, og resultaterne (opgives i
operationer/sekund) vil derfor v re afh ngige af ikke kun browseren,
men ogs PC'ens CPU, hastighed og hvad der ellers foreg r p PC'en.
Med mindre der er tale om afvikling p serveren - hvor det svjks
foreg r i IE10 alt sammen. S er forskellene et udtryk for den
bes gendes forbindelse, og har ikke s meget med browseren at g re. Og
hvad er s form let?

Nej - koden afvikles på klienten. Det er den kode, som du kan se på
selve siden.

Jep... du kan kun se forskellen i performance på de forskellige tests
indenfor samme browser, ikke browserne imellem.

Formålet er at se, hvor optimalt hver browser udfører hver test, så du
kan bedømme, hvilken kode, du vil bruge ud af dem, som du tester på.

Du opstiller nogle ens tests, f,eks.

1. test find char via charAt
2. Find char via slice
3. Find char via index

Eftersom hver test er den samme på alle browsere, kan du se, hvor
optimeret hver browser er i udførelsen af hver test.

Du kan ikke sammenligne _hastighed_ direkte imellem browserne, netop
fordi systemet det kører på ikke oplyses, men du kan se, hvor godt
optimeret hver browsers JS-engine er imod hver test, og så kan du jo
bedømme, om du vil bruge charAt, slice eller index udfra hvad der
synes hurtigst på flest browsere.

Jeg er nok ikke særlig god til at forklare :)

Men kig på try/catch vs. ifCheck undefined f.eks....
http://jsperf.com/try-catch-error-perf/45

Der er tre tests, som laver det samme, men man ved ikke, hvilken, som
er hurtigst.

...teorien er, at der er overhead i try/catch, som man måske kan undgå
med andre metoder som laver det samme, og man bruger så denne side vil
at teste, om det holder vand.

Hvis alle browserne viser, at try/catch er langsommere, må der jo være
noget om det, og så kan man bruge den alternative metode.

Det er særligt interessant, hvis man vil lave webapps, og helt klart,
hvis man vil lave mobilapps i HtML5/JS med AJAX... så vil jeg mene,
man er interesseret i den mest optimale kode.

Man kan iøvrigt også teste alm. Javascript imod frameworks, og det er
der så nogle som har gjort - og frameworks er generelt p... langsomme.
Hvilket jeg så godt vidste :)


MVH
Rune Jensen
MVH
Rune Jensen

[r***@hotmail.com]

Post by r***@hotmail.com

Med mindre der er tale om afvikling p serveren - hvor det svjks
foreg r i IE10 alt sammen. S er forskellene et udtryk for den
bes gendes forbindelse, og har ikke s meget med browseren at g re. Og
hvad er s form let?

Nej - koden afvikles på klienten. Det er den kode, som du kan se på
selve siden.

Skal lige sige, der lader til at være en mulighed for at teste AJAX,
når man lægger sin kode ind... jeg har dog ikke fundet ud af, hvordan
den funktion virker endnu.


MVH
Rune Jensen