Webbapplikationer blir allt mer lika desktopapplikationer vilket innebär att högre prestandakrav ställs på dessa. Ett sätt att möta dessa krav är att bättre utnyttja tillgänglig hårdvara med hjälp av parallellisering. Många webbapplikationer är implementerade i JavaScript. Ett nytt API kallat Web workers möjliggör parallellisering av JavaScript. Web workers har dock vissa begränsningar. Denna studie fokuserar på Web workers applicerat på webbapplikationer med partikelsystem. Partikelsystem har många olika användnings-områden vilket gör att dessa kan användas för många olika typer av tillämpningar. En tillämpning är fysiksimulering i applikationer med realtidsgrafik. Studien undersöker vilka prestandaeffekter tre olika parallelliseringsstrategier implementerade med Web workers ger för fysiksimulering med hjälp av partikelsystem i en webbapplikation. För ändamålet har en enkel applikation utvecklats vilken prestandamätningar utförts med. Resultatet visar att valet av parallelliseringsstrategi begränsas av kommunikationshastigheten till och från Web workers. Ett samband mellan prestanda och antal skickade meddelanden kan påvisas men behöver undersökas närmare.

Webben används i allt större utsträckning som en riktig applikationsplattform, mycket tack vare HTML5. Detta ställer högre krav på webbapplikationens prestanda på klientsidan, då nya tekniker möjliggör mer avancerade applikationer. Parallellisering är en metod för att öka prestandan i applikationer, som dessutom tar nytta av de parallella arkitekturer som idag är vanliga. Web workers – ett nytt API för JavaScript – tillåter en enkel form av parallellisering för webbapplikationer. Dock har web workers en del begränsningar som minskar antalet möjliga strategier. Detta arbete syftar till att utvärdera hur valet av parallelliseringsstrategi påverkar prestandan hos en JavaScript-implementation av marching squares – en algoritm med goda möjligheter för parallellisering. Tre olika strategier implementeras, och utvärderas därefter genom prestandamätning. Resultaten visar att en strategi som använder så lite och så optimerad kommunikation som möjligt ger bättre prestanda än en strategi med mer kommunikation. Vidare arbete för att bland annat utvärdera vinsterna av delat minne föreslås.

Background - Web browsers and and the web programs on them are being used now more than ever in a manner similar to traditional software. But with the increase in the demand for performance on bigger and bigger web applications, there is a need for making the web applications perform faster and better. Introducing parallelism to a normally single threaded system is one popular way of introducing more performance. Objectives - We will implement proven and workable programs, created with OpenMP, that will be translated to JavaScript. These JavaScript applications will use the WebWorkers API to achieve similar levels of parallelism as the OpenMP applications. Methods - To implement and gather results from the all of the various programs, we will be using visual studio code and its live server extension that it hosts to run and compare the JavaScript implementations. The selected OpenMP applications to be measured and translated were primarily taken and selected from a benchmark suite that hosts programs that have already been written in a traditional parallel computing model, such as OpenMP. The performance of these OpenMP programs and Web Workers applications will be analyzed and compared in the second portion of the research where results will be gathered. Results - JavaScript was proven to perform worse than OpenMP in every situation tested. Though this was expected, there were also some situations where JavaScript applications were performing close to the OpenMP programs. Conclusions - Ultimately, using Web Workers is recommended for what they were designed to do. To help alleviate the main thread to keep the web program running smoothly. For the heavy computational tasks that we were experimenting on, JavaScript did not do a sufficient enough job compared against the OpenMP applications. When measuring the workers we did not get any results for any applicationsthat was very close to what OpenMP achieved. Thus Web Workers are really only suited for easy problems that needs to be done repeatedly. They lack the efficiency for any complicated algorithms to be worth implementing

Context - Software applications on the web are more commonly used nowadays than before. As a result of this, the performance needed to run the applications is increasing. One method to increase performance is writing multi-threaded code using Web Workers in JavaScript. Objectives - We will investigate how using Web Workers can increase responsiveness, raw computational power and decrease load time. Additionally, we will conduct a survey that targets software developers to find out their opinions about performance in web applications, multi-threading and more specifically Web Workers. Realization (Method) - We created three experiments that concentrate on the areas mentioned above. The experiments are hosted on a web server inside an isolated Docker container to eliminate external factors as much as possible. To complement the experiments we sent out a survey to collect information of developers' opinions about Web Workers. The criteria for the selection of developers were some JavaScript experience. The survey contained questions about their opinions on switching to a multi-threaded workflow on the web. Do they experience performance issues in today's web applications? Could Web Workers be useful in their projects? Results - Responsiveness shifted from freezing the website to perfect responsiveness when using Web Workers. Raw computational power increased at best 67% when using eight workers with tasks that took between 100 milliseconds and 15 seconds. Over 15 seconds, sixteen workers improved the computational power further with around 3% - 9% compared to eight workers. At best the completion time decreased with 74% in Firefox and 72% in Chrome. Using Web Workers to help with load time gave a big improvement but is somewhat restricted to specific use cases. Conclusions - Using Web Workers to increase responsiveness made an immense difference when moving tasks that is affecting the users responsiveness to background threads. Completion time for big computational tasks was quicker in use cases where you can split the workload to separate portions and use multiple threads in parallel to complete the tasks. Load time can be improved with Web Workers by completing some tasks after the page is done loading, instead of waiting for all tasks to complete and then load the page. The survey indicated that many have performance in mind and would consider writing code in a multi-threaded way. The knowledge about multi-threading and Web Workers was low. Although, most of the participants believe that Web Workers would be useful in their current and future projects, and are worth the effort to implement.