additional information using previous studies

Author: cleophass

src/main/rules/GCI404/python/GCI404.asciidoc

@@ -61,6 +61,20 @@ image::carbone.png[]
 
 For both metrics, the bigger the list, the greater is the gain is.
 
+=== Additional Study
+
+A complementary benchmark from the Creedengo Challenge Issue #113 further supports the recommendation to avoid list comprehensions in loop declarations.
+
+In a controlled containerized test:
+
+The "bad" implementation using a list comprehension consumed: 4,493,365,500 bytes (~4.19 GB)
+
+The "good" implementation using a generator expression consumed: 4,478,423,217 bytes (~4.17 GB)
+
+Memory savings: 14,942,283 bytes (~14.24 MB)
+
+Credit: https://github.com/green-code-initiative/creedengo-challenge/issues/113
+
 === Conclusion
 
 Our analysis clearly demonstrates that replacing list comprehensions with generator expressions in Python for-loops offers substantial benefits in terms of both memory efficiency and environmental impact. As the data size increases, the advantages become increasingly significant.
@@ -69,4 +83,4 @@ Our analysis clearly demonstrates that replacing list comprehensions with genera
 
 Source: https://github.com/green-code-initiative/creedengo-rules-specifications/pull/152
 
-https://docs.python.org/3/howto/functional.html#generator-expressions-and-list-comprehensions
+https://docs.python.org/3/howto/functional.html#generator-expressions-and-list-comprehensions

src/main/rules/GCI72/python/GCI72.asciidoc

@@ -25,24 +25,34 @@ def foo():
 ----
 == Relevance Analysis
 
-The following results were obtained through local experiments.
+The following insights are derived from both local experiments and the study "Comparing Multiple Rows Insert vs Single Row Insert" by Redgate.
 
 === Configuration
-* SQLite Database: 5-6 GB
-* Processor: Intel(R) Core(TM) Ultra 5 135U, 2100 MHz, 12 cores, 14 logical processors
+* SQLite Database: 5–6 GB (local test)
+* Processor: Intel(R) Core(TM) Ultra 5 135U, 12 cores, 16 threads
 * RAM: 16 GB
-* CO2 Emissions Measurement: Using CodeCarbon
+* CO2 Emissions Measurement: CodeCarbon
+* Additional Reference System (Redgate): 
+** SQL Server 2008 R2
+** Database and client application : Lenovo ThinkCentre M90, Windows XP
 
 === Context
 
 This practice can significantly degrade performance, especially when processing large datasets or making repetitive database calls. By opting for batch processing instead of executing queries in loops, developers can improve overall system efficiency and reduce the carbon footprint of their applications.
 
+The Redgate study demonstrated that **batch processing can outperform row-by-row operations by several orders of magnitude**, particularly in data load scenarios. Even with optimized systems like SSIS or high-speed disks, row-level operations remain significantly slower and more resource-intensive. 
+
+These results align with local benchmarks in Python using SQLite.
+
 === Test Execution
 
-The performance analysis was conducted by executing 1000 queries for both the non-compliant and compliant solutions. For the non-compliant solution, each query was executed individually within a loop. For the compliant solution, a batch query with the same 1000 queries was executed.
+Local benchmark compared:
+- 1000 individual `SELECT` queries executed in a loop.
+- A single batched `SELECT` query using `IN (...)`.
 
 === Impact Analysis
 
+*Local benchmark results:*
 [cols="1,1,1", options="header"]
 |===
 |Metric |Compliant Solution |Non-compliant Solution
@@ -53,12 +63,27 @@ The performance analysis was conducted by executing 1000 queries for both the no
 
 *Converter: https://impactco2.fr/outils/comparateur
 
+*Redgate study results:*
+
+
+image::image.png[width=600, align="center", alt="Redgate study results"]
+
+
+[cols="1,1,1", options="header"]
+|===
+|Insert Method |Execution Time (for 1M rows) |Relative Performance
+|Single-row insert in loop |57 seconds |Baseline (slowest)
+|Batch insert (multi-row) |9 seconds |6.3× faster
+|===
+
 === Conclusion
 
 The performance analysis conducted in this study only measures the execution time and carbon emissions of the Python code executing the queries. It does not include emissions due to database processing. 
 
 The results show that the compliant solution, which avoids SQL queries in loops, is more efficient in terms of execution time and carbon emissions. By adopting batch query processing and avoiding queries in loops, developers can improve application performance and reduce their carbon footprint. Developers are encouraged to use batch query processing whenever possible to improve application performance.
 
 === References
+https://www.red-gate.com/simple-talk/databases/sql-server/performance-sql-server/comparing-multiple-rows-insert-vs-single-row-insert-with-three-data-load-methods/
+
 :hide-uri-scheme: 
 https://blogs.oracle.com/sql/post/avoid-writing-sql-inside-loops