Analysis of Measurements

Node.js framework brings its own memory management complexity with it. Secondary error source in table 5.4 is the error in the actual calculation of time difference, which happened few times when executing the measurements. This will cause the mean of previous set to be taken and added, thus lowering the CI and Variance artificially. This particular error was only observed when measuring NodeJS runtime.

Table 5.4. Performance speed results

Configuration Max(ms) Min(ms) Mean(ms) CI Variance

Lap-LwLIoTR-perf 648 620 623 [620, 626] 959

Lap-Node-perf 30 18 23 [21, 25] 266

Rasp-LwLIoTR-perf 6162 6000 6089 [6048, 6130] 168133

Rasp-Node-perf 540 487 503 [490, 516] 16220

5.3.3 Heap memory results

In this section the results from the Measurement Procedure for Heap Memory, described in section 5.2.4 are presented. Table 5.5 shows the results measured for the NodeJS runtime and values calculated frommassif files for LwLIoTR. For LwLIoTR this basically means that only heap data is recorded. In figures 5.1, 5.2 and 5.3 the exact heap graphs that were generated withmassif-visualizerfor LwLIoTR are displayed, and as mentioned in section 5.2.4 there are time intervals for these measurements. First figure is measured with time frame of 60 seconds and second, and third figure are at 60 + 60 seconds time frame.

Possible errors in measurement results can be caused by shutting down the runtime and then restarting it, which will cause that particular runtime to have slightly different results, which is inevitable because there seems to be small problems with the memory management of both runtimes and they leak memory. It is actually unlikely to get exactly the same results after each instantiation of a runtime, especially with the NodeJS runtime, where Node.js framework brings its own memory management complexity with it. However, the scale will still be approximately the same. There is also a possible human error with the calculation of meanTotal heapin LwLIoTR results as, they were calculated by hand.

The difference with Total heapandUsed heap comes from the Node.js memory usage whenTotal heapis the reserved heap size andUsed heapis the actual internally used heap.

This means that onlyTotal heapis calculated for LwLIoTR for any comparisons. Other values recorded with NodeJS runtime are for reference and intrigue.

5.4 Analysis of Measurements 45

Figure 5.1. LwLIoTR heap memory for none application

Figure 5.2. LwLIoTR heap memory for basic application

Table 5.5. Heap memory results

Configuration Max rss Min rss Total heap Total heap Used heap Used heap (KiB) (KiB) max (KiB) mean (KiB) max (KiB) mean (KiB)

Lap-LwLIoTR-none - - 889 498 -

-Lap-Node-none 60428 59589 37156 21269 15775 15262

Lap-LwLIoTR-basic - - 1126 742 -

-Lap-Node-basic 62944 62761 37668 23261 24329 17921

Lap-LwLIoTR-memory - - 148480 49585 -

-Lap-Node-memory 207336 115211 186000 80865 162910 69850

Figure 5.3. LwLIoTR heap memory for memory consuming application

5.4.1 Pmap results analysis

Pmap results from subsection 5.3.1 are divided into 4 categories. These categories are called none,basic,memoryandperformanceand their respective applications areno application, Basic application,Memory heavy applicationandPerformance heavy application. Tables that are used to gather the information from, are tables 5.2 and 5.3. The calculated analysis results are gathered to table 5.6.

When calculatingnoneapplication analysis results, formulanoneLwLIoT R^noneNodeJS is used to calculate relative memory consumption of the runtimes when there are no applications present.

NodeJS runtime uses approximately 6.5-7 times more memory when looking at both platforms respectively when using RSS. The difference with PSS memory consumption calculation is even more drastic as the difference between runtimes is up to 27 times more memory used and same with modified PSS. Although, the difference innonecase is only the overhead between the 2 runtimes. In the future this overhead is taken into account when comparing the memories.

Whenbasicapplication is used, similar amounts of memory is used between the runtimes

5.4 Analysis of Measurements 47 as withnoneapplication. However, there seems to be a case of runtime instance having a noticeably larger memory consumption to none application, in Raspberry PI measurements.

This is likely caused by some deviation from the measurement procedure or simply Node.js garbage collector activating and removing something from the memory. Thus, in this case Raspberry PI measurement is partially ignored, unlessperformaceapplication shows similar results. Although, when looking at table 5.6 the scale is actually similar when comparing to other results, just in negative, probably just a coincidence. If differences betweenbasicapplication andnoneapplication are compared in Laptop for each relevant memory calculation. By using formula basicNodeJS−noneNodeJS

basicLwLIoT R−noneLwLIoT R, RSS memory difference is approximately 5.8 times more memory used, PSS memory difference is approximately 6.4 times more memory and finally for the modified PSS, 6 times more memory is used by NodeJS runtime. Thus, one instance of an ECMAScript application is significantly larger in NodeJS runtime.

Whenmemoryapplication is used, overheads become almost meaningless, so it is easy to look at the memory consumptions and see that NodeJS version uses more memory per allocation. When the same calculations are done for the memory application as for the basic application with formula memoryNodeJS−noneNodeJS

memoryLwLIoT R−noneLwLIoT R. RSS memory difference is 1.45 for the Laptop and 1.83 for Raspberry PI. PSS memory difference is 1.44 for the Laptop and 1.85 for Raspberry PI. Modified PSS memory difference is 1.46 for the Laptop and 1.84 for Raspberry PI. Significantly larger memory allocation size between Laptop and Raspberry PI might be the difference between the Node.js versions. However, LwLIoTR and Duktape still uses significantly less memory per allocation when compared to NodeJS runtime.

Whenperformanceapplication is measured memory wise, results are similar to thebasic application. By using formula per f ormanceNodeJS−noneNodeJS

per f ormanceLwLIoT R−noneLwLIoT R, RSS memory difference is 5.1 times more in Laptop and 4.7 times more in Raspberry PI. PSS memory difference is 5 times more in Laptop and 6.9 times more Raspberry PI. Modified PSS memory difference is 5.4 times more in Laptop and 5.1 times more for Raspberry PI. The scale of the differences is roughly in the same scale, as withbasicapplication.

Overall memory usage with LwLIoTR seems to be on a different level compared to NodeJS runtime. If we do not normalize against the noneapplication the absolute differences between runtimes are up to 16 times more memory used if directly compared withModified PSSmemory. However, most interesting observed values are maximum memory used, which we can directly look at with RSS. This makes LwLIoTR to be in less than 16 MiB range with most ECMAScript applications, that do not intentionally allocate too much memory. Similarly NodeJS runtime has hard time of fitting into a range of 64 MiB as it was exceeded several times in Laptop environment.

Table 5.6. Analysis of memory usage results. Relative usage is generally calculated by NodeJS runtime application as nominator and LwLIoTR application as denominator.

relative-none relative-basic relative-memory relative-performance

(KiB) (KiB) (KiB) (KiB)

Laptop-RSS 6.5 5.8 1.45 5.1

Laptop-PSS 14 6.4 1.44 5

Laptop-mod-PSS 16.6 6 1.46 5.4

PI-RSS 6.9 -6.1 1.83 4.7

PI-PSS 26.7 -10.9 1.85 6.9

PI-mod-PSS 20.2 -6.7 1.84 5.1

5.4.2 Analysis of Perfomance Results

Performance results from section 5.3.2 are fully presented in table 5.4 and configuration name is used to refer to each measurement vector. There are not many interesting or sur-prising things about the performance measurements, unless NodeJS runtime on Raspberry PI outperforming LwLIoTR on Laptop counts as a surprise.

Measurements were adjusted to be run in a reasonable time. Thus, making some of the measurements slightly too small to actually draw any other conclusions, than it is approximately instant as is the case withLap-Node-perf. However, it still possible to see how much faster is the NodeJS runtime compared to LwLIoTR. On laptop the average speed difference is 27 times faster on average. On Raspberry PI the speed difference is on average 12 times, witch can be explained by the earlier version of Node.js and V8 engine at the same time so it is not that surprising.

Overall the NodeJS runtime will outperform LwLIoTR by a margin that is so significant, that there actually is no real comparison in performance. The massive difference can be fully contributed to the difference between Duktape and V8 engines as there is practically no overhead in LwLIoTR implementation of function execution.

5.4.3 Analysis of Heap Memory Results

Heap memory results from section 5.3.3 are fully presented in table 5.5 and the application name is used to refer to a measurement the same way as in section 5.4.1. Full graphs for the heap measurements for LwLIoTR are presented in figures 5.1, 5.2 and 5.3. Only Total heap max andTotal heap avg fields are looked at during the analysis as they are the only fields that can be reasonably calculated from LwLIoTR measurements. There is still the question if these results are reliable. However, it seems like the results are realistic for NodeJS runtime, soprocess.memoryUsagefunction of Node.js seems to work approximately as expected. That said, most of the results analyzed are for the intrigue and are still not fully reliable.

Innoneapplication we can clearly see that LwLIoTR has really low overhead for the run-time itself. Where as, NodeJS runrun-time has quite large default heap size with approximately

5.4 Analysis of Measurements 49 36 MiB. From figure 5.1 we can see in the graph that Duktape heap only consumes 74 KiB in that instance as maximum heap memory usage for LwLIoTR is less than 1 MiB.

Inbasicapplication the Duktape heap usage of LwLIoTR only increases to 200 KiB by 126 KiB and the overall heap consumption increases by 237 KiB whenbasicapplication is added to the runtime and in practice such increases are practically unnoticeable. In NodeJS runtime, the mean total heap increased by approximately 2000 KiB. The figure 5.2 shows the heap fluctuations during the execution of the application. There might multiple reasons for these fluctuations, one is the activation of Duktape garbage collector, another possibility is opening and reading to log file, or it might be practically anything related to thetask function that is being executed. Even the Duktape heap allocation is noticeable but still not overwhelming the overall memory consumption of LwLIoTR. Relative difference with formula basicNodeJS−noneNodeJS

basicLwLIoT R−noneLwLIoT R is only 2.16 times more memory used when calculating Total heap.

Inmemoryapplication the heap usages are overwhelmingly large, thus, it is not practical to think about the heap overhead too much in this case. Inmean Total heapsize, difference between runtimes is quite significant. However, probably in this case the max heap size tells more about the situation at hand as there might be differences that affect the mean too much, as we can seen in figure 5.3, there is a drop in the end that might affect the mean. The relative memory consumption with formula memoryNodeJS−noneNodeJS

memoryLwLIoT R−noneLwLIoT R is 1.008, which makes the actual allocation of memory to be approximately equal.

The heap memory analysis gave us something to think about, if it is actually clear that the LwLIoTR will memorywise still significantly outperform NodeJS runtime on very memory heavy ECMAScript applications as there was some indication that this might not be the case. However, that is quite theoretical as the currentmemory application allocates an array thats size is 5∗10⁶and it is unlikely that larger arrays will be used in ECMAScript applications.