writing

scripts/bundle-size.sh

@@ -19,8 +19,8 @@ export FILE_NAME=$1
 export UNCOMPRESSED_FILE_SIZE=`wc -c < $FILE_NAME`
 export GZIPPED_FILE_SIZE=`gzip -c < $FILE_NAME | wc -c`
 
-echo "Bundle size: $(echo $UNCOMPRESSED_FILE_SIZE | human_print)"
+echo "File size: $(echo $UNCOMPRESSED_FILE_SIZE | human_print)"
 echo "gzipped size: $(echo $GZIPPED_FILE_SIZE | human_print)"
 echo
 echo "Machine readable:"
-echo "BUNDLE_SIZE: $UNCOMPRESSED_FILE_SIZE,$GZIPPED_FILE_SIZE"
+echo "FILE_SIZE: $UNCOMPRESSED_FILE_SIZE,$GZIPPED_FILE_SIZE"

thesis/chapters/03.00-methodology.tex

@@ -106,6 +106,20 @@ caption=Loading coordinates back from module memory,
 label=lst:wasm-util-load-result
 ]{../lib/wasm-util/coordinates.js}
 
+\subsection{File sizes}
+
+For web applications a important measure is the size of libraries. It defines the cost of including the functionality in terms of how much the application size will grow. When it gets too large especially users with low bandwidth are discriminated as it might be impossible to load the app at all in a reasonable time. Even with fast internet loading times are relevant as users expect a fast time to first interaction. Also users with limited data plans are glad when developers keep their bundle size to a minimum.
+
+The file sizes in this chapter will be given as the gzipped size. gzip is a file format for compressed files based on the DEFLATE algorithm. It is natively supported by all browsers and the most common web server software. So this is the format that files will be transmitted in on production applications.
+
+For JavaScript applications there is also the possibility of reducing filesize by code minification. This is the process of reformating the source code without changing the functionality. Optimization are brought for example by removing unnecessary parts like spaces and comments or reducing variable names to single letters. Minification is often done in asset bundlers that process the JavaScript source files and produce the bundled application code. 
+
+For the WebAssembly solution there are two files required to work with it. The wasm bytecode and JavaScript gluecode. The glue code is already minified by the Emscripten compiler. The binary has a size of 3.8KB while the JavaScript code has a total of 3.1KB. Simplify.js on the other hand will merely need a size of 1.1KB. With minification the size shrinks to 638 bytes.
+
+File size was not the main priority when producing the WebAssembly solution. There are ways to further shrink the size of the wasm bytecode. As of now it contains the logic of the library but also necessary functionality from the C standard library. These were added by Emscripten automatically. The bloat comes from using the memory management functions malloc and free. If the goal was to reduce the file size, one would have to get along without memory management at all. This would even be possible in this case as the simplification process is a self-contained process and the module has no other usage. The input size is known beforehand so instead of creating reserved memory one could just append the result in memory at the location directly after the input feature. The function would merely need to return the result size. After the call is finished and the result is read by JavaScript the memory is not needed any more. A test build was made that renounced from memory management. The size of the wasm bytecode shrunk to 507 byte and the glue code to 2.8KB. By using vanilla JavaScript API one could even ditch the glue code altogether\footnote{\url{https://developers.google.com/web/updates/2019/02/hotpath-with-wasm}}.
+
+For simplicity the memory management was left in as the optimizations would require more careful engineering to ensure correct functionality. The example above shows however the there is enormous potential to cut the size. Even file sizes below the JavaScript original are possible.
+
 
 \subsection{The implementation of a web framework}
 \label{ch:benchmark-app}