-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Print ES module dependences from Tracer #46929
base: master
Are you sure you want to change the base?
Conversation
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46929/42995
|
A new Pull Request was created by @wddgit for master. It involves the following packages:
@Dr15Jones, @cmsbuild, @makortel, @smuzaffar can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Size: This PR adds an extra 196KB to repository
Comparison SummarySummary:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments from a first pass
ComponentDescription const* getComponentDescription(ESResolverIndex iResolverIndex) const; | ||
unsigned int getTransitionID(ESResolverIndex iResolverIndex) const; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would you think about dropping the get
prefix?
ComponentDescription const* getComponentDescription(ESResolverIndex iResolverIndex) const; | |
unsigned int getTransitionID(ESResolverIndex iResolverIndex) const; | |
ComponentDescription const* componentDescription(ESResolverIndex iResolverIndex) const; | |
unsigned int transitionID(ESResolverIndex iResolverIndex) const; |
namespace edm { | ||
class EventSetupConsumesInfo { | ||
public: | ||
EventSetupConsumesInfo(std::string_view const& iEventSetupRecordType, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
string_view
can be considered as a lightweight type that would be better passed by value
EventSetupConsumesInfo(std::string_view const& iEventSetupRecordType, | |
EventSetupConsumesInfo(std::string_view iEventSetupRecordType, |
Produces new WhatsIt products for the EventSetup by copying | ||
the products it read. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me it would be more clear to describe already here that the input ES data products are not actually copied.
@@ -75,6 +75,8 @@ namespace edm::eventsetup { | |||
CallbackProductResolver(const CallbackProductResolver&) = delete; | |||
const CallbackProductResolver& operator=(const CallbackProductResolver&) = delete; | |||
|
|||
unsigned int transitionID() const final { return callback_->transitionID(); } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the "counter" for the setWhatProduced()
calls in the ESProducer
, right? I was going to suggest if we could think of a better word (I can see potential confusion with the framework transitions), but I see we already use the transitionID()
term for this purpose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. It is the counter for the setWhatProduced calls in ESProducer. Adding this function to the resolver interface does make the name more visible, but we were already using this name. The transitionID function in CallbackBase was already there and this PR didn't modify that. It also was present in several other files already.
I could change it. We could also leave that for a separate PR. But I can't think of a better name and in some places it is convenient to use the same name as we use in EDConsumerBase. But I agree it leads to some confusion. It has been that way a while.
@@ -197,6 +197,16 @@ namespace edm { | |||
void watchPostEndJob(PostEndJob::slot_type const& iSlot) { postEndJobSignal_.connect_front(iSlot); } | |||
AR_WATCH_USING_METHOD_0(watchPostEndJob) | |||
|
|||
typedef signalslot::Signal<void(PathsAndConsumesOfModulesBase const&, ProcessContext const&)> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the state of PathsAndConsumesOfModuleBase
object in the existing PreBeginJob
signal?
// that is held in memory throughout the job, while the following | ||
// function returns a newly created object each time. We do not | ||
// expect this to be called during a normal production job where | ||
std::vector<eventsetup::ComponentDescription const*> const& esModulesWhoseProductsAreConsumedBy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment describing the return value in similar way to the modulesWhoseProductsAreConsumedBy()
above?
Do you mean whatever |
I noticed that I neglected to implement code to handle the "may consumes" case even though I had thought about it and had a plan for how to do it. I am working on that now. It is mostly just additions to what is already here, not much significant changes in the existing PR code. I'll put it into a separate commit. This version just silently ignores those cases. I need to add a test module using "may consumes". Our current test relies on a lower level unit test. |
PR description:
The Tracer service will print out information about the dependences between modules when the dumpPathsAndConsumes configuration parameter is set true. Before this PR, this information only covered dependences between EDFilters, EDAnalyzers and EDProducers. This PR extends that to also include EventSetup modules. The dependency information it prints is based upon the consumes calls in the C++ code.
Issue #12126 requests this capability. This is an old request, originally from 2015. One weakness of this PR is that the dump is not going to give much insight into what goes on inside PoolDBESSource. Many consumed products will come from that one module.
For the most part, this PR adds and doesn't modify existing code. It shouldn't modify the behavior of the EventSetup. It shouldn't affect output of the program. Mostly it is additional code to get data out of existing data structures that are somewhat difficult to access.
When reviewing this PR, one might benefit by first looking at the following file that contains reference output of a unit test:
There are 5 main parts in the output.
Parts 3 and 5 are new. Parts 2 and 4 have EventSetup dependences added. Note that parts 4 and 5 have detail that includes both consumer and producer transitionID. The transitionID in the EventSetup is the count of the associated setWhatProduced function call in the ESProducer. This might be important because prefetching depends on this and is not done at the level of an entire ESProducer module.
PR validation:
The existing unit test for this dump of information is extended to cover the various EventSetup cases and the output of the dump is compared to a saved reference file known to be correct by manual inspection.