Skip to content
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

Simplify the ReusableObjectHolder #36068

Merged

Conversation

fwyzard
Copy link
Contributor

@fwyzard fwyzard commented Nov 10, 2021

PR description:

Simplify the ReusableObjectHolder:

  • remove unused includes
  • reduce code duplication
  • do not add new objects to the cache before returning them
  • check if try_pop was successful instead of the value of the temporary objects

PR validation:

Unit tests pass.

@fwyzard
Copy link
Contributor Author

fwyzard commented Nov 10, 2021

please test

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36068/26537

  • This PR adds an extra 20KB to repository

@cmsbuild
Copy link
Contributor

A new Pull Request was created by @fwyzard (Andrea Bocci) for master.

It involves the following packages:

  • FWCore/Utilities (core)

@makortel, @smuzaffar, @Dr15Jones can you please review it and eventually sign? Thanks.
@makortel, @felicepantaleo, @wddgit this is something you requested to watch as well.
@perrotta, @dpiparo, @qliphy you are the release manager for this.

cms-bot commands are listed here

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-197053/20423/summary.html
COMMIT: ca0e6ab
CMSSW: CMSSW_12_2_X_2021-11-09-2300/slc7_amd64_gcc900
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/36068/20423/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 42
  • DQMHistoTests: Total histograms compared: 2901890
  • DQMHistoTests: Total failures: 0
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2901868
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 41 files compared)
  • Checked 177 log files, 37 edm output root files, 42 DQM output files
  • TriggerResults: no differences found

@fwyzard
Copy link
Contributor Author

fwyzard commented Nov 10, 2021

By the way, @Dr15Jones @makortel, I think the example for the makeOrGetAndClear method is misleading.
It says:

The primary way of using the class it to call makeOrGetAndClear
An example use would be

auto objectToUse = holder.makeOrGetAndClear(
                            []() { return new MyObject(10); }, //makes new one
                            [](MyObject* old) {old->reset(); } //resets old one
                  );

which seems to imply that old->reset() is called only for objects that are reused.
However, looking at the original implementation:

template< typename FM, typename FC>
std::shared_ptr<T> makeOrGetAndClear( FM iMakeFunc, FC iClearFunc) {
        std::shared_ptr<T> returnValue;
        while ( ! ( returnValue = tryToGet()) ) {
                add( std::unique_ptr<T>(iMakeFunc()) );
        }
        iClearFunc(returnValue.get());
        return returnValue;
}

I think that iClearFunc() is called for any objects before it is returned.

If you confirm that this is desired behaviour (hopefully simplified but unchanged by this PR) I can update the comments as well.

while (!(returnValue = tryToGet())) {
add(makeUnique(iMakeFunc()));
}
std::shared_ptr<T> returnValue = makeOrGet(iMakeFunc);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe doing

Suggested change
std::shared_ptr<T> returnValue = makeOrGet(iMakeFunc);
std::shared_ptr<T> returnValue = makeOrGet(std::move(iMakeFunc));

would avoid a possible copy of the functor.

Possibly an even better solution would be to change the function signature to

makeOrGetAndClear(FM&& iMakeFunc, FC&& iClearFunc)

and then do

Suggested change
std::shared_ptr<T> returnValue = makeOrGet(iMakeFunc);
std::shared_ptr<T> returnValue = makeOrGet(std::forward<FM>(iMakeFunc));

A similar function signature change to makeOrGet would probably be required to get the most benefit of such a change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change

    template <typename FM, typename FC>
    std::shared_ptr<T> makeOrGetAndClear(FM&& iMakeFunc, FC iClearFunc) {
      std::shared_ptr<T> returnValue = makeOrGet(std::forward<FM>(iMakeFunc));
      iClearFunc(returnValue.get());
      return returnValue;
    }

should be enough, since iMakeFunc is the only one that is copied.

Copy link
Contributor Author

@fwyzard fwyzard Nov 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least, my confused understanding is that FC iClearFunc (in makeOrGetAndClear) and F iFunc (in makeOrGet) should already take any of the functors by reference if they are lvalues.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think using FC instead of FC&& means the compiler (before optimization) will call the move constructor of FC when passed an lvalue. I'd bet that all compilers will remove that call when optimation is turned on. However, using FC&& does make the requirements of the arguments more explicit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wrong. I tested in godbolt and for the case where the object is created directly in the argument list they are identical.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does appear that if the argument is created outside of the function argument list, then FC&& is the better choice as it does avoid an extra copy.

https://godbolt.org/z/7fYG641qq

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, done - let me know if I missed anything (here or elsewhere).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I missed the last comment...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...done, now.

@fwyzard
Copy link
Contributor Author

fwyzard commented Nov 11, 2021

please test

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36068/26575

  • This PR adds an extra 16KB to repository

@fwyzard
Copy link
Contributor Author

fwyzard commented Nov 12, 2021

If you confirm that this is desired behaviour (hopefully simplified but unchanged by this PR) I can update the comments as well.

The unit test seem to agree that iClearFunc should always be called, both on reused and on new objects, e.g.:

{
edm::ReusableObjectHolder<int> intHolder;
auto p = intHolder.makeOrGetAndClear([]() -> int* { return new int(1); }, [](int* iV) { *iV = 0; });
CPPUNIT_ASSERT(p.get() != 0);
CPPUNIT_ASSERT(*p == 0);
auto p2 = intHolder.tryToGet();
CPPUNIT_ASSERT(p2.get() == 0);
}

So, I'm not sure how

   auto p = intHolder.makeOrGetAndClear([]() -> int* { return new int(1); }, [](int* iV) { *iV = 0; }); 

is better than

   auto p = intHolder.makeOrGet([]() -> int* { return new int(1); }); 
   *p = 0;

?

It doesn't seem to be used anywhere in CMSSW. On the other hand, it doesn't add any complexity or cost.

I'll update the comments, though.

@fwyzard
Copy link
Contributor Author

fwyzard commented Nov 12, 2021

please test

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-36068/26592

  • This PR adds an extra 20KB to repository

@cmsbuild
Copy link
Contributor

Pull request #36068 was updated. @makortel, @smuzaffar, @Dr15Jones can you please check and sign again.

@cmsbuild
Copy link
Contributor

+1

Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-197053/20486/summary.html
COMMIT: 35efc5c
CMSSW: CMSSW_12_2_X_2021-11-11-2300/slc7_amd64_gcc900
Additional Tests: THREADING
User test area: For local testing, you can use /cvmfs/cms-ci.cern.ch/week0/cms-sw/cmssw/36068/20486/install.sh to create a dev area with all the needed externals and cmssw changes.

Comparison Summary

Summary:

  • No significant changes to the logs found
  • Reco comparison results: 6 differences found in the comparisons
  • DQMHistoTests: Total files compared: 42
  • DQMHistoTests: Total histograms compared: 2902040
  • DQMHistoTests: Total failures: 11
  • DQMHistoTests: Total nulls: 1
  • DQMHistoTests: Total successes: 2902006
  • DQMHistoTests: Total skipped: 22
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.004 KiB( 41 files compared)
  • DQMHistoSizes: changed ( 312.0 ): 0.004 KiB MessageLogger/Warnings
  • Checked 177 log files, 37 edm output root files, 42 DQM output files
  • TriggerResults: no differences found

@makortel
Copy link
Contributor

+1

@cmsbuild
Copy link
Contributor

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)

@perrotta
Copy link
Contributor

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants