## 6 Experimental Evaluation  
In order to evaluate the performance of \(Incremental^{h}\), we compared its execution time against that of a single-shot (i.e., non-incremental) execution of clingo. To do this, we generated sets of observations about sequences of time steps of progressively increasing length from 1 to 114 steps, representing a typical test input for the user-facing application. Then, we ran the instances with both \(Incremental^{h}\) and clingo (in single-shot mode) in order to calculate the corresponding trajectories. The single-shot version of the program was obtained as described in Section 4.  
The experiments were executed on a computer running CentOS 7, equipped with an Intel Xeon CPU E5-2699 v3 at 2.30 GHz, 24 GB RAM, and using clingo 5.4.0, the version of clingo for whose incremental API \(Incremental^{h}\) was developed. \(Incremental^{h}\) was implemented in Python and configured as clingo's control custom loop for the incremental runs. Every run was set up with a timeout of 1 h. The results are shown in Figures 2-4.  
Clingo in single-shot timed out 23 times out of 114, i.e., about 20% of the time. The average execution time of the instances that did not time out was 7.3 s, with a standard deviation of 16.7 and a maximum execution time of 141.39 s. If one factors in the instances timed out, then the average time increased to 732.1 s.  
_Incremental\({}^{h}\)_ never timed out. The average execution time was within the requirements for practical use, with an average time of 4.1 s, a standard deviation of 2.4, and a maximum execution time of 10.4 s.  
Comparing the performance of the two provides some clear indications of the greater consistency of _Incremental\({}^{h}\)_. To begin with, the 23 timeouts of the single-shot version are of course extremely problematic for practical use. _Incremental\({}^{h}\)_ does not pose such an issue since it never timed out. Having said that, before the experimental phase of this project, we were unsure how _Incremental\({}^{h}\)_ would compare with the single-shot version on instances where the latter would not time out. In fact, _Incremental\({}^{h}\)_ involves a rather complex algorithm that is implemented in Python and runs as clingo's control loop. The single-shot version, on the other hand, relies on clingo's default control loop, which is written in highly optimized C/C++. On simpler instances, we suspected that the single-shot version may be faster. Furthermore, while indeed there is a number of simple instances in which the single-shot version is marginally faster, its performance rapidly degrades, as indicated by the higher values of average time (7.3 s-or 732.1 s!-vs. 4.1 s), standard deviation (16.7 vs. 2.4), and substantially higher maximum execution time (141.3 s vs. 10.4 s). All in all, our experiments demonstrate the exceptional capabilities of clingo's support for incremental computations, which enabled us to develop an ASP-based solution that featured consistently fast execution. The results also demonstrate the practical viability of our approach for extending the use of incremental computations to situations where straightforward encodings fail to satisfy the conditions of the Module Theorem.  
An noteworthy observation on the single-shot instances that resulted in a time out is that, in all cases, the computation timed out during the grounding phase of the process. In fact, it would appear that, in those instances, the size of the grounding grows very dramatically, ultimately leading to either a time out or, if no time out is set, to an out-of-memory condition. We believe this to be an observation that has important implications on which other possible approaches are applicable to this problem. We comment on this topic in Section 10.  
Figure 2: Comparison of the execution times for all instances.