Merge pull request #376 from cleophass/rules_doc

Add documentation for rules: GCI10, GCI203, GCI404, GCI72, GCI74, GCI7.

Author: dedece35

src/main/rules/GCI10/python/GCI10.asciidoc

@@ -39,3 +39,34 @@ SVG images generated by common drawing softwares contains unnecessary data: calc
     <circle cx="104.02724" cy="152.19028" r="73.177132" style="fill:#ff00ff;stroke-width:0.264583"/>
 </svg>
 ----
+
+== Relevance Analysis
+
+The following results were obtained through local experiments.
+
+=== Configuration
+
+* SQLite Database: 5-6 GB
+* Processor: Intel(R) Core(TM) Ultra 5 135U, 2100 MHz, 12 cores, 14 logical processors
+* RAM: 16 GB
+* CO2 Emissions Measurement: Using CodeCarbon
+
+=== Context
+ 
+For example, by using SVGOMG, a tool for optimizing SVGs, we were able to reduce the file size from 22 KB to 11 KB, a 50% reduction. This is useful for page loading or data storage.
+
+image::image.png[]
+
+=== Test Execution
+
+For this analysis, we simulated a process of manipulating these SVG files. The objective was to measure the impact of file size on CO2 emissions. We used an "optimized" SVG file and a "non-optimized" SVG file. The modification consisted of changing certain parts of the SVG and saving the final result.
+
+=== Impact Analysis
+
+image::output.png[] 
+
+=== Conclusion
+
+The emissions with the non-optimized file are 1.3928360831225074e-08, while the emissions with the optimized file are 9.68571752760373e-09, representing a 30% reduction in emissions.
+
+We recommend incorporating file optimization techniques as part of our standard development practices and exploring additional opportunities to reduce the environmental impact of our digital products.

src/main/rules/GCI10/python/image.png

@@ -83,3 +83,30 @@ Or
     // ...
 }
 ----
+
+== Relevance Analysis
+
+The following results were obtained through local experiments.
+
+=== Configuration
+
+* SQLite Database: 5-6 GB
+* Processor: Intel(R) Core(TM) Ultra 5 135U, 2100 MHz, 12 cores, 14 logical processors
+* RAM: 16 GB
+* CO2 Emissions Measurement: Using CodeCarbon
+
+=== Context
+
+This rule depends heavily on the context. For simple icon, the use of SVG is relevant because they will be lighter than their JPG counterparts. However, for more complex images, such as photographs, SVG will be heavier.
+
+Example: for the same photo in JPG, it will be 370 KB and in SVG, it will be 830 KB.
+
+image::photo.png[]
+
+This is because the vector format is not suitable for details, it is suitable for simple shapes (circle, line, icon, etc.). It has advantages in this area because it is not composed of pixels, it is extremely scalable. In the following cases: data science, convolutional neural networks, multimodal models, OCR, the SVG format is not suitable, it is preferable to use JPG or PNG. And this, because the models were trained on JPG and PNG formats and this is the input format of the CNNs, the use of SVG would involve additional preprocessing of the image. For example, the well-known CIFAR-10 dataset is in JPG format as can be seen in the following image, representing the architecture of a CNN.
+
+image::CNN_architecture.png[]
+
+=== References
+https://www.tensorflow.org/tutorials/images/cnn?hl=fr
+https://www.researchgate.net/publication/373715986_Convolutional_Neural_Network_CNN_The_architecture_and_applications

src/main/rules/GCI10/python/output.png

@@ -20,3 +20,67 @@ for var in [var2 for var2 in range(100)]:
 for var in (var2 for var2 in range(100)):
     ...
 ----
+
+== Relevance Analysis
+
+The following results were obtained through local experiments.
+
+Credit : https://github.com/AghilesAzzoug
+
+=== Configuration
+
+12th Gen Intel Core I7-12700H
+16 Gb RAM (4800 Mhz)
+Windows 11 OS version 22H2
+Python 3.9.15
+memory_profiler==0.61.0 (for RAM experiments)
+codecarbon==2.1.4 (for CO2 emissions)
+
+=== Context
+
+The use of generator expressions instead of list comprehensions in for-loops declaration can save RAM usage. It has multiple benefits like reducing CO2 emissions as well as releasing memory constraints on the hardware.
+Python generators resemble lazy lists from other programming languages: when iterated over, they compute their values on the fly. They lack some list behaviors (indexing, len method, ...) but are memory-efficient, as they do not store each of their values in memory, unlike lists. Thus, when declared in a for-loop declaration, list comprehensions can be safely replaced with generator expressions.
+For more details on list comprehensions vs generator expressions, see Python documentation.
+
+
+=== Impact Analysis
+
+
+Local experiments* on list comprehensions vs generator comprehensions gives the following results on:
+
+*1. Memory usage:*
+
+image::memory.png[]
+
+*2. Co2 Emissions*
+
+Using CodeCarbon we get the following results:
+https://codecarbon.io/
+
+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.
+
+=== References
+
+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

src/main/rules/GCI203/python/CNN_architecture.png

@@ -34,3 +34,52 @@ client.age # Récupérer l'attribut age
 client.age = 26 # Modifier l'attribut age
 ----
 
+== Relevance Analysis
+
+The following results were obtained through local experiments.
+
+=== Configuration
+- Processor: Intel(R) Core(TM) Ultra 5 135U, 2100 MA1Hz, 12 cores, 14 logical processors
+- RAM: 16 GB
+- CO2 emissions measurement: Using CodeCarbon
+- Memory usage measurement: Using psutil
+- Time measurement: Using timeit
+
+=== Impact Analysis
+
+To measure the impact of using getters and setters, we created two classes: one with getters and setters and the other without. We then measured the memory usage of each class. Additionally, we measured the execution time of each class using timeit. Below is the code used to evaluate both time and carbon emissions.
+
+[source,python]
+----
+class Direct():
+    def __init__(self, age):
+        self.age = age  
+
+
+class WithGetter():
+    def __init__(self, age):
+        self._age = age
+
+    def get_age(self):
+        return self._age
+
+----
+
+=== Results
+image::tracking_1.png[]  
+
+
+For 100,000,000 iterations, the difference in CO2 equivalent emissions is 3.7*10^-6, which corresponds to 17 mm in equivalent emissions of a thermal car (see converter).
+
+:hide-uri-scheme: 
+https://impactco2.fr/outils/comparateur
+
+=== Conclusion
+
+Based on the results, we can conclude that using getters and setters in a class increases carbon emissions and execution time. Therefore, it is recommended to avoid them when possible. The performance difference comes from the overhead of method calls.
+
+It is important to keep in mind that for security or control reasons, the use of getters and setters may be necessary. In such cases, using the @property decorator can be a good alternative to traditional getters and setters. It allows restricting access to the attribute and adding logic when the attribute is accessed or modified. Performance is better than recreating getter and setter methods but not as good as direct attribute access.
+
+=== References
+:hide-uri-scheme: 
+https://www.datacamp.com/tutorial/property-getters-setters