web workers

Tags:    javascript

<< < 123 > >>
Hej jeg har den her side hvor man kan teste hvor mange tegn browseren kan gemme i localStorage og sessionStorage :
http://scootergrisen.dk/htmlgrisen/eksempler/eksempel0008.html

Nu vil jeg gerne lave siden om så den bruge web workers som jeg forstår skulle være godt til sådan en opgave.

Testen lider nemlig under at processbaren ikke opdater sig før hele testen af slut i de fleste browsere og det lidt ærgeligt det er meningen man under testen skal kunne følge med på processbaren og se hvor langt man er nået.

Nå men nu er jeg så lige idag gået igang med at lære om web workres så kender det ikke endnu men jeg kan se at man ikke har adgang til window objecktet fra en webn worker og dermed heller ikke localStorge og sessionStoage...

Så hvordan skal jeg kunne lave min test med web workers ?

Jeg ville jo gerne putte localStorage.setItem('', e.data); i min web worer fil men det kan jeg jo så ikke.

Fik afvide noget af min kode var ueffektiv.
Så fik jeg afvide jeg kunne skrive data = new Array(10000000).toString(); i stedet.

Er der en endnu bedre måde at lave en lang streng på hvor der skal være et vist antal tegn i ?




Indlæg senest redigeret d. 29.07.2012 06:09 af Bruger #13010
24 svar postet i denne tråd vises herunder
2 indlæg har modtaget i alt 6 karma
Sorter efter stemmer Sorter efter dato
Det er nu ikke hukommelsesforbruget jeg er bekymret over, men kørselstiden. Desto mere der skal allokeres jo langsommere går det. Nogle smart implementeringer af Javascript kan muligvis også bruge den eksisterende allokering og på en smart måde forlænge den. Men i min erfaring er det stadig forholdsvist langsomt. Strenges immutabilitet er en af årsagerne til at man har StringBuilder klasser i visse sprog.

Er godt klar over hvad hans opgave går ud på. Han laver en binær søgning for hvor meget plads ved at lave en streng i størrelsen mellem max og min. Hensigten med min forklaring var at det ikke var en god ide at bygge denne "test"-streng inkrementielt.

Har ligge kigget ind på Scooters kode og kan se han laver den i et hug. Men da jeg ville nævne strenges immutabilitet kiggede jeg på Jakobs kode.

Rettede lige min tekst ovenover med en interessant note. Hvis man bygger en 5MB streng 64 bytes ad gangen ender man med at allokere samlet 205GB.




Jakob tak det hjalp sørge noget med den kode.

Nu har du godt nok brugt setTimeout() men jeg vil jo gerne have mulighed for man kan trykke på stop knappen så det hele kan afbrydes.
Hvordan laver jeg det om ?

Også vil det være meget rart hvis den stopper ved 50MB for eksempel men det syntes jeg ikke virker, i Firefox der forsætter den bare.

Og ja ved godt jeg er handikappet men jeg forstår bare ikke særlig meget af det hele.

Her er koden indtil videre : http://scootergrisen.dk/test/test0154.html



Indlæg senest redigeret d. 30.07.2012 16:17 af Bruger #13010
Ser ud til at være den her linje der skaber problemet:
Fold kodeboks ind/udJScript kode 


I en binær søgning halverer man altid søgeområdet. Men den her tillader en test-strengs størrelse at overskride det og dermed ignorere upper. Hvis du i stedet:
Fold kodeboks ind/udJScript kode 

Så bør det virke. Og du kan fjerne limit de andre steder i funktionen.

EDIT: En parantes for meget

EDIT2: (kunne ikke lavet et nyt indlæg...)

Ser ud til at jeg var lidt forkert på den tidligere. Efter lidt googling har jeg fundet kilder der forklarer at streng-konkatenering i Javascript faktisk er effektiv nu: http://stackoverflow.com/questions/7299010/why-is-string-concatenation-faster-than-array-join. Der var også nogle interessant videnskabelige artikler der forklarer hvordan man implementerer sådanne strenge.

Men vil dog lige påpege at der stadig findes en god del sprog hvor det ikke er så effektivt. Og jeg vil gætte på at hvis man hopper et par år tilbage så var det også tilfælde for Javascript.



Indlæg senest redigeret d. 30.07.2012 17:15 af Bruger #14645
@Søren, jeg benytter ikke en incrementive algoritme, så derfor burde min løsning ikke lide (i samme grad) af det problem du nævner.

Jeg har nok ikke været lidt utydelig. Jeg mente longString funktionen. F.eks. har du 2,5MB og vil nu teste for 3,75MB, så lægger du ca. 100KB til indtil du er mere eller lig med og så reducerer du. Men det var da jeg troede at Javascript havde en primitiv streng konkatenering hvor den ville lave mange strenge på 2,5MB+ indtil den nåede 3,75MB. Siden Javascript har en effektiv strengkonkatering er det ikke noget problem.


Ja, strenge er immutable, men eftersom det er 'toString' delen og ikke selve allokeringen af arrayet der tager tid, er jeg nød til lave en streng ud af det hver gang, i stedet for bare at benytte et array, som man kunne pushe yderligere bytes til.

Det kom jeg også frem til da jeg prøvede at allokere i et hug (dengang jeg troede Javascript have primitiv konkatenering).


Nu var det her bare en hurtig løsning, da jeg ikke ville bruge for lang tid på det, men jeg kan forestille mig at ArrayBuffer og alle de nye TypedArrays ville være bedre egnet til denne opgave, men det må Scootergrisen selv ligge og rode med (Det er vel faktisk en meget god introduktion til netop disse).

Faktisk en god idé til senere Scootergris.


EDIT 2:: @Søren: Det er rigtigt at det ikke er en "ren" binær-søgning, men det skyldes at det implementation du benytter nu starter ved at allokere halvdelen af "max", og derved hvis Scootergrisen har behov for at tjekke for op til 50MB, starter den med at allokere 25MB (som er en tidskrævende process, og det ville gå hurtigere hvis man startede nedefra og arbejdede sig op.)

Igen tror jeg var nok utydelig. Jeg har ikke ment den var binær. Godt tænkt med at starte fra bunden og arbejde op. Det havde jeg ikke lige umiddelbart tænkt over :)

Der er dog lige problemet med limit som overskrider upper. Ved mig ender den ved at Javascript får en exception ved allokering af 256M tegn. En mulig løsning er at sætte limit til sand hvis den overvejer en size der er større:
Fold kodeboks ind/udJScript kode 





Indlæg senest redigeret d. 30.07.2012 18:46 af Bruger #14645
<< < 123 > >>
t