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
Improve PluginDescription with VPSets #35477
Conversation
This allows the ParameterSetDescription to be different for each element of a VPSet in the special case where the elements hold a PluginDescription.
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35477/25640
|
A new Pull Request was created by @wddgit (W. David Dagenhart) for master. It involves the following packages:
@makortel, @smuzaffar, @cmsbuild, @Dr15Jones can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
@@ -124,7 +124,7 @@ namespace edm { | |||
|
|||
void validate_(ParameterSet& pset, std::set<std::string>& validatedLabels, bool optional) const final { | |||
loadPlugin(findType(pset)); | |||
cache_->validate(pset); | |||
parameterSetDescription_->validate(pset); |
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.
The parameterSetDescription_
appears to be used only right after loadPlugin()
. How about loadPlugin()
would return the ParameterSetDescription
object for which the validate()
(and writeCfi()
below) are called?
Or is there some other need to keep the object alive longer?
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.
I agree with Matti.
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.
I agree also. That is even better. I made the change and am running the unit tests. I will push it as soon as they complete. Thanks.
@Dr15Jones Do you have any concerns? |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8c4756/19256/summary.html Comparison SummarySummary:
|
Thinking a bit more, what if we took a different tack. Keep the |
@Dr15Jones We could do that, but this cache isn't helping much anyway. If I am remembering how this works, we create a description run the validation for one module label and the description gets deleted. It doesn't help in cases where a VPSet isn't used, because it is only used once. Even with a VPSet it would only help if there were consecutive elements of the same plugin type. The current issue is the first case where VPSet is used at all and Matti said they are only going to put one or two elements in the VPSet and it sounds like the types are different... Maybe this is premature or even unnecessary optimization... I only see 4 cases where the PluginDescription is used at all (hopefully that will change, I think there are significantly more cases where it would be useful...) I don't feel strongly. What you suggest will work and if you and Matti agree I will put it in. At worst it slightly complicates the code in PluginDescription. Is there some use case where this optimization will make a significant performance difference? |
I have no problem dropping the |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-35477/25660
|
please test |
Pull request #35477 was updated. @makortel, @smuzaffar, @Dr15Jones can you please check and sign again. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-8c4756/19293/summary.html Comparison SummarySummary:
|
+1 |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @perrotta, @dpiparo, @qliphy (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This allows the ParameterSetDescriptions to be different for each element of a VPSet in the special case where the elements hold a PluginDescription. Previously all elements would need to have the same plugin type.
PR validation:
Extended an existing unit test to cover this case. It seems to only really be different in the ParameterSetDescription part of things in a minor way.