43 lines
7.2 KiB
TeX
43 lines
7.2 KiB
TeX
\section{Discussion}
|
|
|
|
In this section the results are interpreted. This section is structured in different questions to answer. First it will be analyzed what the browser differences are. One section will deal with the performance of the pure JavaScript implementations while the next will inspect how Simplify.wasm performs. Then further insights to the performance of the WebAssembly implementation will be given. It will be investigated how long it takes to set up the WebAssembly call and how much time is spent to actually execute the simplification routines. Next the case of Turf.js will be addressed and if its format conversions are reasonable under specific circumstances. Finally the performance of mobile devices will be evaluated.
|
|
|
|
\subsection{Browser differences for the JavaScript implementations}
|
|
|
|
The first thing to see from the results of chapter \ref{ch:case1} and \ref{ch:case3} is that there is actually a considerable performance difference in the two versions of Simplify.js. So here we take a closer look at the JavaScript performance of the browsers. Interestingly clear winner between the similar algorithms cannot be determined as the performance is inconsistent across browsers. While the original version is faster in Firefox and Safari, the altered version is superior in Chrome and Edge. This is regardless of whether the high quality mode is switched on or not. The difference is however more significant when the preprocessing step is disabled.
|
|
|
|
In figure \ref{fig:win_chro_simplify_vs_true} and \ref{fig:win_edge_simplify_vs_true} one can see how similar Chrome and Edge perform with high quality mode enabled. When disabled however the algorithms perform similar in Edge (figure \ref{fig:win_edge_simplify_vs_true}) while in Chrome the alternative version still improves upon the original.
|
|
|
|
In Firefox the result is very different. Without the high quality mode the original version performs about 2.5 times better than the alternative. Figure \ref{fig:win_ffox_simplify_vs_false} shows this. When disabling the preprocessing the performance gain is even higher. the original performs constantly 3x faster as seen in figure \ref{fig:win_ffox_simplify_vs_true}.
|
|
|
|
The same results can be reproduced under Firefox on macOS with the "Bavarian outline" dataset (figures \ref{fig:mac_ffox_bavaria_vs_false} and\ref{fig:mac_ffox_bavaria_vs_true}). Interestingly under safari the algorithms perform similarly with a small preference to the original version. This applies to either case tested (figures \ref{fig:mac_safa_bavaria_vs_false} and \ref{fig:mac_safa_bavaria_vs_true}).
|
|
|
|
With so much variance it is hard to determine the best performing browser regarding the JavaScript implementation. Under the right circumstances Chrome can produce the fastest results with the alternative implementation. Safari is consistently very fast. Even while it falls short to Firefox's results with the original algorithm when high quality is turned on. The greatest discrepancy was produced by Firefox with high quality requested. There the alternate version produced the slowest results while the results with Simplify.js can compete with Chrome's results with the Simplify.js alternative. Edge lies between these two browsers with not too bad but also not the fastest results.
|
|
|
|
\subsection{Browser differences for Simplify.wasm}
|
|
|
|
So diverse the results from last chapter were, so monotonous they will be here. The performance of the Simplify.wasm function is consistent across all browsers tested. This is a major benefit brought by WebAssembly often described as predictable performance.
|
|
|
|
The variance it very low when the preprocessing is turned off through the high quality mode. The browsers produce about the same runtimes under the same conditions. When high quality is off the Chrome browser got its nose ahead with a mean runtime of 0.66ms. Edge follows with 1.02ms and Firefox takes an average 1.10ms. The results of chapter \ref{ch:case3} show that Safari is a bit faster at the high quality mode than Firefox but slower without.
|
|
|
|
\subsection{Insights into Simplify.wasm}
|
|
|
|
So for when the performance of Simplify.wasm was addressed it meant the time spent for the whole process of preparing memory to running the algorithm in wasm context to loading back the result to JavaScript. This makes sense when comparing it to the JavaScript library with the motive to replace it one for one. It does however not produce meaningful comparisons of WebAssembly performance in contrast to the native JavaScript runtime.
|
|
|
|
This is because until Simplify.wasm actually gets to the WebAssembly computation it will take some time to prepare the data and load it back afterwards. To see how long that is the additional chart type "Simplify.wasm runtime insights" was created. In figures \ref{fig:win_edge_simplify_stack_false} and \ref{fig:win_edge_simplify_stack_true} the results can be seen. Each data point contains a stacked column to represent the proportion of time spent for each task. The blue section represents the time spent to initialize the memory, the red one the execution of the compiled WebAssembly code. At last the green part will show the time spent for getting the coordinates back in the right format.
|
|
|
|
First the parts where JavaScript is run will be examined. There is as good as no variance in the memory initialization. This is obviously due to the fact that this step is not dependent on any other parameter than the polyline length. Initial versions of the library produced in this thesis were not as efficient in flattening the coordinate array as the final version. By replacing the built-in \texttt{Array.prototype.flat}-method with a simple for loop a good amount optimization was achieved on the JavaScript side of the Simplify.wasm process. The flat method is a rather new feature of ECMAScript and its performance might be enhanced in future browser versions. This example shows however that when writing JavaScript code one can quickly deviate from the "fast path" even when dealing with simple problems.
|
|
|
|
On the other side of process lies the function \texttt{loadResult}. It is dependent on the size of the resulting polyline. Since this is often very low in the examples used the green bar can be rarely seen. Merely at low tolerance values like in figure \ref{fig:win_edge_simplify_stack_false} the influence is visible. The maximum fraction there is at tolerance value 0.05 where the operation takes 4.26\% of the total execution time.
|
|
|
|
Now when comparing the two graphs one can clearly see that the influence of the JavaScript portions is much greater when the high quality mode is turned of. The time taken for preparing the memory in both cases is about 0.67ms. The execution time of the algorithms is so low in the first case, that it comes down to making up only 24,47\% when taking the median values. In case where high quality is enabled the results do not look as drastic. The median value of execution time is 4.31ms and with that much greater than preparation time. If JavaScript is at advantage in the first case and the high execution time justifies the switch of runtimes in the latter will be examined in the next chapter.
|
|
|
|
|
|
\subsection{Comparison Simplify.wasm vs Simplify.js}
|
|
\todo[inline]{when is what faster}
|
|
|
|
\subsection{Analysis of Turf.js implementation}
|
|
\todo[inline]{When is turf.js faster}
|
|
|
|
\subsection{Mobile device analysis}
|