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
<runeof...@gmail.com> wrote:

>Hvis nogen gider teste i IE9+10, ville det v�re rart.
>
>http://jsperf.com/string-charat-vs-slice/2

[Birger Sørensen]

Rune Jensen skrev den 3/24/2013:
> 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

--
http://varmeretter.dk - billig, sund og hurtig mad
Utils http://sdccms.dk/ordbog/ http://sdccms.dk/mailfriend/
http://bredelund.dk CMS som det var meningen et sï¿œdant skulle vï¿œre

[runeof...@hotmail.com]

On 24 Mar., 20:04, Birger Sørensen <s...@bbsorensen.com> wrote:
> Rune Jensen skrev den 3/24/2013:
>
>
>
>
>
>
>
>
>

> > 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

[runeof...@hotmail.com]

On 24 Mar., 19:44, Jens Peter Karlsen <jpkarl...@mvps.org> wrote:
> 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

[runeof...@hotmail.com]

On 25 Mar., 15:44, runeofdenm...@hotmail.com wrote:

> > 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