## 4 Experimental Results
### Initialization and Start Times  
The first set of experimental tests measures the required time to initialize and start the sidecar object and all its inner components associated to five full processing chains (corresponding to five MQTT topics) that has to be synchronized with the cloud.  
Figure 7a shows the initialization times of the higher level components of the sidecar object. The GoogleCloudModuleManager is the component that needs more time to be initialized since the communications between sidecar object and cloud is performed through the internet connectivity instead of a local communication. The five SidecarForwarders on the contrary have a limited influence on the overall startup time, as proof that the structures adopted during implementation add an extremely low overhead to startup times. It is important to note that the sum of the startup times showed in the graph is not equal to the total sidecar object startup time, as the initialization of GoogleCloudModuleManager and SmartObjectModuleManager (as explained in the Implementation section) is performed on separated threads running in parallel; the average startup time of the entire sidecar object resulting from the tests is 1229.8 ms, with a standard deviation of 178 ms. In Figure 7b are reported the results relative to the starting times of the same components.  
Figure 7: (**a**) Sidecar object modules initialization times; (**b**) sidecar object modules start times; (**c**) smart object modules initialization times; (**d**) smart object modules start times; (**e**) Google Cloud Modules initialization times; (**f**) Google Cloud Modules start times; (**g**) Google Cloud Communication Modules initialization times and (**h**) smart object modules start times.  
As expected, starting times were significantly lower than the startup times, since they are associated only the startup of Java Threads for each component. In Figure 7c are shown the results related to the initialization times of the inner modules of the smart object module.  
The SmartObjectConnectionOperator took much more time to be initialized compared with the SmartObjectSubscriber, since it had to setup the secure connection through the use of cryptographic keys. Figure 7d depicts start times of the same components.  
Considering that both SmartObjectConnectionOperator and SmartObjectSubscriber ran on a single thread, the startup times were extremely low (\(\sim\)1 ms) Figure 7e shows the initialization times of the GoogleCloudModule submodules. Presented results show that, as expected, the communication manager had the most relevant impact on the overall timing due to the remote connection with the cloud services. On the other hand the initialization of internal and local components (such the five MessageProcessors in this case) is barely perceptible.  
For completeness, in Figure 7f are reported the start times relative to the last components analyzed. As for the other cases analyzed, starting times are much lower of initialization times, as consequence of the implementation choices made. The last (and probably more significant) test results are related to the inner components of the GoogleCloudCommManager: in Figure 7g are detailed the initialization times of such components. As expected, RegistryOperator and ConnectionOperator are the most expensive in terms of initialization. It is also important to note that those two modules run sequentially, as the RegistryOperator must be necessarily executed before the MQTT connection with the Google Cloud API. Figure 7h confirms that the starting times of the components inside the Google Cloud Communication Module are in line with the results registered for previous submodules.