cmssw: Slowness in cmsRun starts

Last week @Dr15Jones and I noticed some slowness in cmsRun job startups (like up to 20 min). I noticed today

26-Jul-2021 16:08:26 CEST  Initiating request to open file file:step2.root
26-Jul-2021 16:08:28 CEST  Successfully opened file file:step2.root
%MSG-e HLTConfigProvider:  METAnalyzer:pfMetDQMAnalyzerMiniAOD@beginRun  26-Jul-2021 16:13:59 CEST Run: 274199
Begin processing the 1st record. Run 274199, Event 39389360, LumiSection 21 on stream 0 at 26-Jul-2021 16:15:00.232 CEST

in https://github.com/cms-sw/cmssw/pull/34621#issuecomment-886933695.

I then tested locally workflow 10024.0 in CMSSW_12_0_X_2021-07-26-1100, and noticed the step2 to take 2 minutes from Successfully opened file and Begin processing the 1st record. The job really should not take 2 minutes to get there.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 64 (63 by maintainers)

Most upvoted comments

I think I need to inject it here: https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TMuon/python/simDigis_cff.py#L16 and other trigger cff files that load the muon trigger.

Seems reasonable. In principal, any configuration that directly names the module of type ‘CSCTriggerPrimitivesProducer’ should have the ESProducer added. I do such checks by doing

> git grep CSCTriggerPrimitivesProducer | grep '\.py'

In that case only one hit

L1Trigger/CSCTriggerPrimitives/python/cscTriggerPrimitiveDigis_cfi.py:    "CSCTriggerPrimitivesProducer",

so it looks like this is more useful

> git grep cscTriggerPrimitiveDigis_cfi | grep '\.py'

which yields

DQM/L1TMonitor/python/L1TStage2Emulator_cff.py:from L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi import *
L1Trigger/CSCTriggerPrimitives/README.md:The configuration for the CSC local trigger is `cscTriggerPrimitiveDigis_cfi`. By default it is integrated into the standard L1 sequence which can be found [here](https://github.com/cms-sw/cmssw/blob/master/L1Trigger/L1TMuon/python/simDigis_cff.py#L15-L20). When emulating ALCTs/CLCTs/LCTs on simulated wire and comparator digis, the inputs are `"simMuonCSCDigis:MuonCSCWireDigi"` and `"simMuonCSCDigis:MuonCSCComparatorDigi"` respectively. When re-emulating ALCTs/CLCTs/LCTs from unpacked wire and comparator digis - from real LHC data, or GIF++ test-beam data - the inputs are `"muonCSCDigis:MuonCSCWireDigi"` and `"muonCSCDigis:MuonCSCComparatorDigi"` respectively. The configuration of the CSC local trigger as part of the standard L1 sequence on data can be found [here](https://github.com/cms-sw/cmssw/blob/master/L1Trigger/Configuration/python/ValL1Emulator_cff.py#L88-L96).
L1Trigger/CSCTriggerPrimitives/test/deprecated/CSCTriggerPrimitivesReader_cfi.py:from L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi import cscTriggerPrimitiveDigis
L1Trigger/CSCTriggerPrimitives/test/runCSCTriggerPrimitiveProducer_cfg.py:process.load("L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi")
L1Trigger/CSCTriggerPrimitives/test/runL1CSCTPEmulatorConfigAnalyzer_cfg.py:process.load('L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi')
L1Trigger/Configuration/python/L1MuonEmulator_cff.py:from L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi import *
L1Trigger/Configuration/python/ValL1Emulator_cff.py:from L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi import *
L1Trigger/Configuration/python/ValL1Emulator_cff.py:valCscTriggerPrimitiveDigis = L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi.cscTriggerPrimitiveDigis.clone()
L1Trigger/Configuration/python/customiseReEmul.py:    from L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi import cscTriggerPrimitiveDigis
L1Trigger/L1TMuon/python/simDigis_cff.py:import L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi
L1Trigger/L1TMuon/python/simDigis_cff.py:simCscTriggerPrimitiveDigis = L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi.cscTriggerPrimitiveDigis.clone(
L1Trigger/L1TMuonEndCap/test/RunTrackFinder_MC.py:process.load('L1Trigger.CSCTriggerPrimitives.cscTriggerPrimitiveDigis_cfi')

@dildick thanks for the quick turn around! I have a few comments

const edm::ParameterSet& pset_;

needs to be

const edm::ParameterSet pset_;

as the lifetime of the object passed to the module’s constructor is not guaranteed to be longer than the module.

In your set functions, e.g.

void set_cclutPosition(const t_lut& lut) { cclutPosition_ = lut; }

pass the argument by value and then do a std::move

void set_cclutPosition(t_lut lut) { cclutPosition_ = std::move(lut); }

Then when calling the set_ function also do a std::move

lut-> set_cclutPosition(std::move(cclutPosition));

This will avoid a copy of the entire container. [NOTE: your code does not actually call set_cclutPosition, it actually calls set_cclutSlope twice!]

You can get rid of the statics

static const std::vector<int> wg_min_hs_ME1a_;

and, instead, in the .cc file just use an anonyous namespace with constexpr std::arrays. It will give you the same interface but will be built at compile time, not shared library load time.

namespace {
constexpr  std::array<int, 48> CSCALCTCrossCLCT::wg_min_hs_ME1a_ = {...};
...
}