# New and Efficient Algorithms for Producing Frequent Itemsets with the Map-Reduce Framework
## 4 Incremental Frequent Itemset Mining with Map-Reduce
### Experimental Evaluation
#### 4.3.5 Results  
Figure 9a,b demonstrate the run and CPU times of each algorithm for dataset T20 on GCE cluster of size 5 and _minSup_ 0.1%. It shows that incremental algorithms behave better than full in both parameters. The increase in delta size increases the computation time. Figure 9c,d are similar to Figure 9a,b, but they depict the algorithm's behavior for _minSup_ 0.2%. In this case, the run time of \"Delta\" is higher than \"Full\" and \"DeltaMin\" behaves almost the same as \"Full\". The CPU time of \"Delta\" and \"DeltaMin\" is still lower than that of \"Full\". \"DeltaMinKeep\" is better by all parameters than \"Full\". The large difference between \"DeltaMinKeep\" and \"DeltaMin\" is explained by eliminating the need to run the recount Job in old \(\mathcal{D}\). Figure 9e,f show the algorithm's run, and CPU time behavior for T20, _minSup_ 0.1%, and _inc_ 10% as the GCE cluster size changes from 5 to 10, and to 20 nodes/cores. We can see that the incremental algorithms scale well with more cores added to the system, although it is not linear. \"Full\" recalculation scaled even worse when the cluster size changed. This is explained by the fact, that as long as theinput data size divided by the number of workers is larger than the HDFS block size, each mapper gets exactly the same Split, and its work is the same. Once the cluster size scales above this point, the data split size gets lower than the HDFS block. In most algorithms, the smaller the input, the faster the algorithm runs. In our case, this is true for the counting jobs (second step of IMRApriori or recounting in case of old DB check) and the \"Join\" job. The first step of IMRApriori finds all FI of its data split by running Apriori on its data Split. This algorithm is not linear in its input size and may perform worse on a very small input size (see Section 4.2.4). Figure 9g,h show the algorithm's run and CPU time behavior for WebDocs, _minSup_ 15% and _inc_ 10% as GCE cluster size changes from 5 to 10 and to 20 nodes/cores. We can see that incremental algorithms scale well when more cores are added to the system. \"Full\" recalculation CPU time does not scale that well when cluster size changes, similar to the previous case. Figure 9i,j show WebDocs with _minSup_ 20% run, and CPU time as delta size varies. It shows that run time of \"Delta\" is no better than \"Full\", but its CPU time is better. Figure 9k,l show similar graphs to Figure 9i,j, but for _minSup_ 15%. As frequent itemset mining for _minSup_ of 15% is more computationally extensive than 20%, the resulted times are higher. We can see that in this case, all incremental algorithms behave much better than the full algorithm. In some cases, a full run takes 2-3 times longer than incremental algorithms. Figure 9m,n are similar to Figure 9k,l, but show a close up of the incremental algorithms only, and their run/CPU times. It shows that \"Delta\" behaves worse than \"DeltaMin\", and \"DeltaMin\" behaves worse than \"DeltaMinKeep\". Our evaluation shows that the incremental algorithms do similarly or better than full recalculation on smaller sized datasets with larger support in terms of CPU time, while the Run time was not always better for less optimized \"Delta\" and \"DeltaMin\" algorithms  
As the support threshold decreased, all incremental algorithms had better Run and CPU times than \"Full\" re-computation. They outperformed the \"Full\" algorithm several times (in some of the tests, even by a factor of 10). The explanation for this is that more time is required to mine FI than just doing candidate counting. The Run and CPU times of \"DeltaMin\" is always superior to \"Delta\". \"DeltaMinKeep\" showed results superior to \"DeltaMin\" according to Run time and CPU time. The large differences were observed in execution when the algorithm managed to completely eliminate the counting step of old \(\mathcal{D}\). Algorithm run time and CPU time showed almost linear growth with an increase in input size (increase in \(\Delta\) size), as long as the Split size stayed constant.