Makes some tests run in parrallel

[ribalba]

I played around a little with ChatGPT to speed up the tests. It's not great but shaves off a little. Also it doesn't add to much to the complexity. The problem I see is that we need to add new test files to the mapping.

@arne what do you think?

[github-actions]

Eco CI Output - Old Energy Estimation

Eco CI Output [RUN-ID: 23307336582]:

Label	🖥 avg. CPU utilization [%]	🔋 Total Energy [Joules]	🔌 avg. Power [Watts]	Duration [Seconds]
Measurement #1	28.7297	6407.55	4.14	1546.89
Total Run	28.73	6407.55	4.14	1546.89
Additional overhead from Eco CI	N/A	19.44	4.37	4.45

🌳 CO2 Data:
City: CONSTANT, Lat: , Lon:
IP:
CO₂ from energy is: 1.480144050 g
CO₂ from manufacturing (embodied carbon) is: 0.441349077 g
Carbon Intensity for this location: 231 gCO₂eq/kWh
SCI: 1.921493 gCO₂eq / pipeline run emitted

---

Total cost of whole PR so far:

[github-actions]

Eco CI Output [RUN-ID: 23307656771]:

Label	🖥 avg. CPU utilization [%]	🔋 Total Energy [Joules]	🔌 avg. Power [Watts]	Duration [Seconds]
Measurement #1	29.1987	6319.62	4.17	1514.18
Total Run	29.20	6319.62	4.17	1514.18
Additional overhead from Eco CI	N/A	17.46	4.27	4.09

🌳 CO2 Data:
City: CONSTANT, Lat: , Lon:
IP:
CO₂ from energy is: 1.459832220 g
CO₂ from manufacturing (embodied carbon) is: 0.432016462 g
Carbon Intensity for this location: 231 gCO₂eq/kWh
SCI: 1.891849 gCO₂eq / pipeline run emitted

---

Total cost of whole PR so far:

[ArneTR]

I am totally in favor of getting the pipeline testing times down.

However I am not clear about the results of this approach. The testing time shows as ~26 Minutes here https://github.com/green-coding-solutions/green-metrics-tool/actions

If I look into prior runs I can see that this is even above average with runs like this https://github.com/green-coding-solutions/green-metrics-tool/actions/runs/23172928702 taking only 23+ mins to run.

Is there a bug?

What is the expected saving in terms of time on your box?

[ribalba]

I didn't enable it for ci/cd tests as I don't think they will be a lot faster as they don't have that many CPU cores. This is for local tests whereas the speed increase is also not that huge on my machine.

[ArneTR]

Hmm, I am not sure if that is then the way forward ...

To my understanding the script selects tests files to be save to run in parallel. I believe this will create a lot of mental complexity and should not be the first target.

I would argue it is far easier to optimize inside a file, where we have DB reset / Data loading all in one scope.

The overwhelming amount of time happens in 4 files:

• test_frontend.py
• test_volume_loading.py
• test_usage_scenario.py
• test_runner.py

If we strip these down to run internally in parallel (by maybe hot-patching the config.yml and spinning up multiple DBs or creating different schemas inside the DB) we can at least half the test time I would argue.

What do you say?

[ribalba]

Yes but that seemed like a lot of work and would add a lot of complexity. This was a simple fix that makes it faster but does not add a lot of overhead and complexity. Creating new tables etc ... seemed like a lot of work. I agree that this would be nice but I also see us working a week on this and then having something very unmaintainable and when there is an error we don't know why. The test are already very very flaky so I wouldn't want to introduce even more variance.

[ArneTR]

Here a dump of the timings of the relevant test files for exact time overview: