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)
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
In that case only one hit
so it looks like this is more useful
which yields
@dildick thanks for the quick turn around! I have a few comments
needs to be
as the lifetime of the object passed to the module’s constructor is not guaranteed to be longer than the module.
In your
setfunctions, e.g.pass the argument by value and then do a
std::moveThen when calling the
set_function also do astd::moveThis will avoid a copy of the entire container. [NOTE: your code does not actually call
set_cclutPosition, it actually callsset_cclutSlopetwice!]You can get rid of the
staticsand, instead, in the .cc file just use an anonyous namespace with
constexprstd::arrays. It will give you the same interface but will be built at compile time, not shared library load time.