I den här rapporten presenteras och implementeras ett mer lagringseffektivt sätt att köra kod på mikrokontrollers. Det jämförs också med det traditionella sättet detta görs på. Metoden involverar en hopptabell och målet är att kunna köra större mängder kod än vad som kan lagras på mikrokontrollern. Utan att förlora för mycket prestanda.I slutändan finns det inget självklart svar på om systemet som implementerats är ett bra alternativ till traditionella applikationer. Fler faktorer än bara prestanda presenteras och måste beaktas när system implementeras. Den utvecklade prototypen introducerade en overhead på cirka 1%. Därför kunde slutsatsen dras att prototypen är ett rimligt alternativ (prestandamässigt) till det traditionella sättet att köra applikationer. / In this paper, a more storage efficient way of running code on microcontrollers is presented, implemented and compared against the conventional method. The method involves utilising a jump table and the objective is to be able to execute larger amounts of code than fits into the program memory of the microcontroller. Without loosing too much performance.In conclusion, there is no obvious answer to whether the implemented system is a viable alternative to traditional applications or not. More variables than just performance are brought up and must be considered when a system is implemen- ted. However, the developed prototype introduced a minor overhead of about 1%. It could therefore be concluded that the prototype is a viable alternative, to the conventional way of running applications, performance-wise.

One problem that has been plaguing software development is the multitude of platforms that are available to users. Consequentially, a company needs to provide its service on multiple devices, running different operating systems, in order to reach as many end-users as possible. This leads to increased development complexity and costs. To solve this issue, multiple cross-platform solutions have been proposed throughout the years. One such solution is Progressive Web Application, a set of techniques that aim to create web applications with features that have traditionally only been available to native applications. In recent years WebAssembly, a compilation target that allows languages other than JavaScript to run on the browser, has been introduced. With its compact binary format and compiled nature, its goal is to bring speed and performance enhancement to web applications. This thesis analyzes WebAssembly in the context of building a Progressive Web Application, particularly the impacts it has on the performance and memory usage. A comparison is made with the JavaScript library ReactJS. The results indicate that a Progressive Web Application built with WebAssembly achieves similar performance results as one built using ReactJS when it comes to computers, but performs worse on mobile platforms. The results also indicate that using a programming language such as Rust, although still introducing memory overhead, minimizes the bundle size and runtime memory consumption of the application. / Ett problem som har plågat mjukvaruutveckling är mängdenplattformar som är tillgängliga för användare. Följaktligen måste ett företagtillhandahålla sin tjänst på flera enheter, som kör olika operativsystem,för att nå så många slutanvändare som möjligt. Detta leder till ökadutvecklingskomplexitet och kostnad. För att lösa detta problem har flera plattformsoberoendelösningar föreslagits genom åren. En sådan lösning är Progressiva Webapplikationer, en samling tekniker som syftar till att skapa webbapplikationer med funktioner som traditionellt bara varit tillgängliga förmobilapplikationer. Under de senaste åren har ett verktyg som ger andra språk än JavaScript möjligheten att köras i webbläsaren introducerats. Detta verktyg är WebAssembly. Med sitt kompakta format och kompilerade natur, har den som mål att förbättra prestanda för webbapplikationer. Detta arbete analyserar WebAssembly i samband med utvecklingen av en Progressiv Webapplikation, specifikt inverkan den har på prestanda och minnesanvändning. En jämförelse görs med JavaScriptbiblioteket ReactJS. Resultaten tyder på att en Progressiv Webapplikation byggd med WebAssembly uppnår liknanderesultat som en byggd med ReactJS när det kommer till datorer, men presterar sämre på mobila plattformar. Resultaten visar också att användningen av ett programmeringsspråk som Rust minimerar paketstorleken och minnesanvändningen av applikationer även om det fortfarande introducerar minneskostnader.

All embedded systems are unique, a design that is suitable for one system can rarely be copied over to another. This inherently makes designing embedded systems difficult. The difficulty is only amplified by the uncertainty of the future requirements as it is developed over time. Being able to continuously validate the performance and the reliability is of great importance to be able to ensure fault proof execution.This thesis explores two areas. A method of tracking the static and dynamic memory usage of a system is crucial to ensure correct functionality under all conditions, and that the implemented hardware will suffice. Multiple possible tools, each functioning uniquely, were developed and tested to find the most suitable for measuring the memory usage of the elevator system. Additionally the message usage, i.e. the way the different units within the studied system communicate with each other, was scrutinized for possible performance and reliability enhancements. A study was made for the most optimal communication protocol, and for how the transmissions could be improved upon.The results show that for this specific system, the best way of calculating the memory usage is with a tool developed within this project. Using this tool it was found that none of the modules in the elevator system use more than 30 % of the available memory during execution. The message usage study shows the most optimal protocol is CAN with the ISO 15765-2 upperlevel protocol, which is the one currently in use. However, improvements to the message transmissions are suggested, such as taking full advantage of the CAN protocol and by implementing message buffers on the receiving end.An important conclusion is that just as there is no unique system design that fits all, there is no memory measurement tool or message usage implementation that fits all systems. Each system has to be analyzed to find the most optimal solution for that particular system. / Alla inbyggda system är unika, en design som passar ett system kan sällan kopieras över till ett annat. Detta leder till att det är svårt att designa inbyggda system. Osäkerheten över framtida systemkrav då systemet utvecklas över tid gör inte designproblemet lättare. Att kontinuerligt kunna validera prestandan och pålitligheten är viktigt för att kunna garantera felfri körning.Detta examensarbete utforskar två områden. En metod för att mäta den statiska och dynamiska minnesanvändningen av systemet är nödvändig för att kunna säkerställa att systemet alltid fungerar som det ska, och att den tillgängliga hårdvaran är tillräcklig. Flera olika verktyg utvecklades och testades för att hitta det som bäst mäter hissens minnesanvändning. Utöver det granskades meddelandeanvändningen, hur de olika enheterna inom det studerade systemet kommunicerar med varandra, för potentiella förbättringar av prestandan och pålitligheten. En studie utfördes för att hitta det mest optimala kommunikationsprotokollet, och för hur av överföringarna kunde förbättras.Resultatet visar att för det här specifika systemet är bästa sättet att räkna ut minnesanvändningen med ett verktyg utvecklat under projektet. Med hjälp av det här verktyget visas att ingen av modulerna i hissystemet använde mer än 30% av det tillgängliga minnet under körning. Studien över minnesanvändningen påvisar att det mest optimala protokollet var CAN och ISO 15765-2 för det övre lagret, vilket är det som används för nuvarande. Dock föreslås förbättringar till hur meddelandena överförs, till exempel genom att utnyttja CAN protokollet till fullo och genom att implementera meddelandebufferts på mottagarsidan.En betydelsefull slutsats som drogs var att på samma sätt som det inte finns en unik systemdesign som passar alla system, finns det inte heller ett minnesanvändningsverktyg eller en meddelandeanvändning som passar alla system. Varje enskilt system måste analyseras för att hitta den mest optimala lösningen för det specifika systemet.

Dagens applikationer hanterar mer och mer data vilket resulterar i att de blir allt mer resurskrävande och kräver mer av hårdvaran. Vilket i förlängningen kan innebär att hårdvaran måste bytas ut med jämna mellanrum för att kunna köra mjukvaran på ett för användaren tillfredsställande sätt. Detta arbete undersöker om det genom att byta designteknik är möjligt att utveckla mindre resurskrävande applikationer. Arbetet presenterar en jämförelse mellan objektorienterad design (även kallad objektorienterad programmering, OOP) och data orienterad design (DOD). Detta genom att dels ta upp kända för- och nackdelar med respektive designteknik samt genom att utföra en mätning på respektive teknik. Det som anses vara de främsta fördelarna med OOP är återanvändning av kod, att koden är lätt att underhålla, säkerhet i form av inkapsling samt att objekten som används reflekterar den mänskliga verkligheten. Dessa fördelar är dock även något som bidrar till det som anses vara den främsta nackdelen med OOP, nämligen att den är prestandakrävande. När det gäller DOD så anses de främsta fördelarna vara att det medför en cachevänligare kod som leder till färre cachemissar. Det anses även vara lättare att parallellisera koden i jämförelse med OOP. Den nackdelen som tas upp med DOD är att de tar tid att lära sig och kräver en del övning. Dock är DOD väldigt okänt vilket resulterade i ett svagt underlag. Två simuleringar utvecklades i Unity varav den ena använder sig av den nya teknikstacken DOTS som är dataorienterad. Resultatet av mätningarna indikerar på att DOD använder mindre av hårdvaruresurserna vid prestandakrävande applikationer. Om applikationen ej är prestandakrävande märks dock ingen skillnad mellan de olika teknikerna vid fråga om processoranvändning. / Today, applications handle more and more data, which results in them becoming increasingly resource-intensive and requiring more of the hardware. Which in the long run may cause that the hardware must be replaced at regular intervals to be able to run the software in a way that is satisfactory for the user. This thesis investigates whether it is possible to get less resource-intensive applications by changing the design technology. The paper presents a comparison between object-oriented design (also known as object-oriented programming, OOP) and data-oriented design (DOD). This is performed by addressing the known advantages and disadvantages of each design technique and by measuring each technique in the matter of performance. What was considered to be the main advantages of OOP is the reuse of code, that the code is easy to maintain, security in the form of encapsulation and that the objects that are used reflect human reality. On the other hand, these advantages also contribute to what is considered to be the main disadvantage of OOP, namely that it is performance-intensive. When it comes to DOD, the main advantages are considered to be that it results in a more cache-friendly code that leads to fewer cache misses. DOD is also considered easier to parallelize the code compared to OOP. The disadvantage of DOD is that it is time consuming to learn and requires some practice. Though, DOD is very unknown which resulted in a narrow basis. Two simulations were developed in Unity, one of which uses the new technology stack DOTS, which is data-oriented. The results of the measurements indicate that DOD uses less of the hardware resources in performance-intensive applications. If the application is not performance-intensive, though, no difference is noticed between the different technologies when it comes to CPU-usage.

This study evaluates the performance of Kotlin and Java on Android Runtime using four benchmarks from the Computer Language Benchmarks Game suite, for which a total of 12 benchmark implementations are studied. The metrics used to evaluate the performance includes runtime, memory consumption, garbage collection, boxing of primitives as well as bytecode n-grams. To benchmark the languages, a benchmark application has been developed intended to run on an Android phone. The results indicate that Kotlin is slower than Java for all studied benchmarks by a varying factor. Furthermore, the use of idiomatic Kotlin features and constructs results in additional heap pressure and the need of boxed primitives. Other interesting results indicate the existence of an underlying garbage collection overhead when reclaiming Kotlin objects compared to Java. Furthermore, Kotlin produces larger and more varied bytecode than Java for a majority of the benchmarks. / Denna studie utvärderar prestandan mellan Kotlin och Java på Android Runtime genom 12 implementationer av fyra benchmarks från The Computer Language Benchmarks Game. De mätvärden som använts för att utvärdera prestandan inkluderar körtid, minnesanvändning, garbage collection, boxing av primitiver samt bytekod n-grams. För att benchmarka språken har en benchmarkapplikation tagits fram för Android. Resultaten visar att Kotlin är långsammare än Java för samtliga benchmarks. Vidare resulterar användandet av idiomatiska Kotlin-funktioner i ökad minnesanvänding samt behovet att representera primitiver som klasser. Andra intressanta resultat inkluderar existensen av en overhead för garbage collectorn för frigörandet av objekt som allokerats av Kotlin jämfört med Java. Vidare producerar Kotlin större bytekodfiler och uppvisar mer varierad bytekod än Java för en majoritet av de benchmarks som studerats.