Sa mt copy

[gautierbureau]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?

Close issue #1442

What kind of change does this PR introduce?

What is the current behavior?

What is the new behavior (if this is a feature change)?

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

[antoinebhs]

@gautierbureau I tested this PR against main on the same setup as #1442:

• ~20,000 buses
• ~9,000 contingencies

8 threads

Main vs NETWORK_PER_THREAD_MODE=COPY
CONTINGENCY_PARTITIONING_MODE=SLICE

Main	COPY + SLICE
1125 s	1047 s (-7%)

Main vs NETWORK_PER_THREAD_MODE=COPY
CONTINGENCY_PARTITIONING_MODE=ROUND_ROBIN

Main	COPY + ROUND_ROBIN
1125 s	828 s (-36%)

---

64 threads

Main vs NETWORK_PER_THREAD_MODE=COPY
CONTINGENCY_PARTITIONING_MODE=SLICE

Main	COPY + SLICE
321 s	353 s (+10%)

Main vs NETWORK_PER_THREAD_MODE=COPY
CONTINGENCY_PARTITIONING_MODE=ROUND_ROBIN

Main	COPY + ROUND_ROBIN
321 s	271 s (-15%)

The COPY optimization only does not show significant improvements (in my use case, it's even a regression for the 64 threads case depending on the contingency slicing I guess).
COPY + ROUND_ROBIN has an important impact on results, thread utilization is significantly more balanced, with workers finishing at nearly the same time. I think that we can improve a bit the 64 threads results, it looks like some threads are not fully used between 50 and 100s of calculation (?). It might be something to look after

I observed a memory use jump in the 64 threads case (+30%) but I didn't look at it in details and it might not be confirmed but it's something to check I think. Maybe just a JVM behavior.

cc @geofjamg @SylvestreSakti

Note: after a quick look it looks like the slow down between 50 and 100s of calculation is due to calculating a batch of non-converging contingencies.