30 lines
5.4 KiB
TeX
30 lines
5.4 KiB
TeX
\section{Conclusion}
|
|
|
|
%In this section a conclusion is drawn. First the results will be shortly summarized. The work done will be reflected and possible improvements are suggested. At last there will be an prospect about future work.
|
|
|
|
In this thesis, the performance of simplification algorithms in the context of web applications was analyzed. The dominant library for this task in the JavaScript ecosystem is Simplify.js. It implements the Douglas-Peucker algorithm with optional radial distance preprocessing. By using a technology called WebAssembly, this library was recreated with the goal to achieve a better performance. This recreation was called Simplify.wasm. Also a JavaScript alternative to Simplify.js was tested that operates on a different representation of polylines. To perform several benchmarks on different devices a website was built. The results were gained by using the library Benchmark.js which produces statistically relevant benchmarks.
|
|
|
|
It was shown that the WebAssembly based library showed more stable results across different web browsers. The performance of the JavaScript based ones varied greatly. Not only did the absolute run times vary. There were also differences in which variant was the faster one. Generally it can be said that the complexity of the operation defines if Simplify.wasm is preferable to Simplify.js. This comes from the fact that there is an overhead of calling Simplify.wasm. To call the WebAssembly code the coordinates will first have to be stored in a linear memory object. With short run times this overhead can exceed the performance gain through WebAssembly. The pure algorithm run time was always shorter with WebAssembly.
|
|
|
|
The alternative Simplify.js version was created because another major library, Turf.js, implemented an odd routine for simplification. To call Simplify.js the data format of the polyline was transformed back and forth. It could be shown that this process has negative impact to performance in most browsers. Merely one browser showed faster runtimes with this method when the run time of the algorithm was high.
|
|
|
|
The integration of a WebAssembly module requires more effort than a JavaScript one. Especially as this is a rather recent technology. Hurdles are the sparse tooling, the limited support by older browsers and the necessity to bring in another programming language. While the first two points will develop to the better over time the latter one is tackled by promising projects like AssemblyScript which compiles a subset of TypeScript to WebAssembly.
|
|
|
|
\subsection{Improvements and future work}
|
|
|
|
% file size
|
|
The library created in this thesis can be improved in a few aspects. First, there is the excessive file size produced by the Emscripten compiler. Section \ref{ch:file-sizes} already mentions this issue. A solution is proposed to reduce the size of the byte code to about 500 bytes gzipped. This optimization is achieved by not using standard library functions. Only then will the library be contestable to the JavaScript original in this regard.
|
|
|
|
% memory management
|
|
Another improvement can be made by changing the abstractions implemented in JavaScript. These were constructed with the goal to achieve a similar experience to Simplify.js. The whole memory management is encapsulated in these abstractions. Each call leads to allocating and freeing the memory for the polyline. One could provide a better interface to the memory management where the user of the library can preload a polyline and execute the algorithm on the prepared memory. Another approach could be to make use of serialized geodata. Whole feature sets could be represented in a binary encoding and simplified in one WebAssembly call.
|
|
|
|
% three dimensions
|
|
The geodata types mentioned in this thesis, namely GeoJSON and TopJSON, allow for three dimensional coordinates. This third value often represents altitude. The library Simplify.js provides alternate source code to operate on those types of coordinates. The library created here did not implement a solution for them. If provided, Simplify.wasm will ignore the third coordinate value and run the algorithm on the two dimensional polyline. The functionality could be extended to support calculations on three dimensional positions.
|
|
|
|
% psimpl.h
|
|
As mentioned WebAssembly gives the ability to bring code from other programming languages to the web. A library was found that implements several different simplification algorithms in C++. This library can be compiled to WebAssembly. A successful build was developed in the early stages of this thesis. The outcome was not as appropriate for a performance analysis as the direct port of the JavaScript library. In a future work however, this ported library can be used for quality analysis of the different algorithms.
|
|
|
|
% compare with native
|
|
The main goal projects like WebAssembly is to bring the web platform up to speed with native applications. Especially in the beginning of JavaScript the code that could run in web browsers was slow compared to those. Since then JavaScript engines have evolved and brought huge performance gains, for example by just-in-time compilation. WebAssembly could be a way to reduce the gap to native execution even further. It will be interesting to see how much the cost of running a virtual machine in the browser really is. The code from Simplify.wasm can easily be compiled by general C compilers. A comparison of the native execution to the results from this thesis would be interesting.
|
|
|