Let me first explain what I have noted:
During patch-set run executed with Prometheus, the execution time of the patch increase during the patch-set. They are patch-set with at maximum 3500 patches and with not more than 20 RGB levels.

The issue can be replicated with virtual probe. What i did was to run a 6 cube starting from a 21 cube measurement (close to 10000 patches) and the same one with CS clean measurements.
From this recording you can visually note the difference. Basically the same patch-set execution is doubled when run over an already measured patch-set.

Honestly I would expect some differences (CS always check if a patch has been measured to overlap it), but doubling? Also because I see similar execution with the 5500 patch-set I have pointed here, with that (absurd) number of RGB levels.

It is difficult for me to tell what is the root cause, so I cannot tell if I am spotting a bug, or a possible Wibini

Based on the information provided in the other post on the slowdown with excessive RGB levels, along with the ability to display the profile in a text editor, different profiling modes, etc., I will leave you to workout the answer.

Hint: it is not a bug.

Steve

I have run 2 18 cube patch-set, generated based on the built--in 18 cube with the anisometric option.
I have reordered them having one with primaries at the beginning and another one with primaries at the end (attached)
Primary at the end takes (with virtual probe, on my PC) 31m:15s, the other one 20m:08. Let say that measuring primaries at the beginning takes 55% more.
I cannot find in my mind any root cause based on what you have written above.
Basically I can understand that populating an RGB level takes more, but why the presence of RGB levels impacts on other patches (execution time)

Attached file: Different RGB patch position