…erial.xml. I presume the pixfwdblade.*Zplus had been done to distinguish from the pixfwdblade[0-9]:PixelForwardBlade. But this is not recessary, because the pixfwdblade[0-9]:PixelForwardBlade are not called in any geo scenario where data/PhaseI/trackerRecoMaterial.xml is used.

…these paths are not looped over when not needed anyway, hence this commit has no effect on workflow perf).

… has very small, but non-null, impact on perf.

…erial.xml. Very significant perf improvement. This version is compatible to work on both DDD and dd4hep cases.

…ngMaterialGroups_ForPhaseI.xml, version working for both DDD and dd4hep.

…try scenarios.

…al.xml. This has no visible impact on perf though (~85s before and after this commit), but does not harm to have a more compact file. Regex removal instead (in the previous commits) had a big impact: full DD4hep step 1 up to event generation: ~140s -> ~85s !!

…s groups.

…lysis/test

…ow (~5 s gain in my local for overall step 1 XML parsing / geo construction). When SpecPar blocks jave same name, all paths are gathered unnecessarily, leading to loop over more paths (with regex) than needed).

…alsenspmf.xml, HcalProdCuts.xml

…/2021/v1/hcalsenspmf.xml, data/v1/HcalProdCuts.xml to data/HcalProdCuts/2021/v2/HcalProdCuts.xml, data/v1/trackingMaterialGroups_ForPhaseI.xml to data/trackingMaterialGroups_ForPhaseI/v1/trackingMaterialGroups_ForPhaseI.xml.

…a data/v1 directory) to geometry scenarios