Project

General

Profile

Bug #7057

Bug #6394: Verify that association query objects are created outside tight loops

FindManyP() usage in TrackStitcher module

Added by Gianluca Petrillo over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Reconstruction
Target version:
-
Start date:
09/22/2014
Due date:
% Done:

100%

Estimated time:
1.00 h
Occurs In:
Experiment:
LArSoft
Co-Assignees:
Duration:

Description

TrackStitcher module shows non-optimal usage of associations.

larreco/TrackFinder/TrackStitcher_module.cc

I notice dubious practises in TrackStitcher::GetHitsFromComponentTracks() and TrackStitcher::GetSpacePointsFromComponentTracks().

The action I recommend:
- since you use it, #include "art/Framework/Core/FindManyP.h"
- bring the FindManyP instances out of the loops
- since the two functions are called in a loop themselves, I recommend to pass the query object as a constant reference argument to them, and to define the query object itself in the TrackStitcher::produce() method.
- I still can't guess the reason for the use of the temporary argument p in initializing the query

Contact people: Wesley Ketchum (), Eric Church ()

History

#1 Updated by Eric Church over 6 years ago

Investigating.

#2 Updated by Eric Church over 6 years ago

  • Status changed from Assigned to Resolved

Setting this issue to Resolved.

Per Gianluca's recommendations, FindManyP() pulled out of loops where possible, left as-is when in try{} blocks. Include FindManyP.h, const ref& used where possible, auto temporaries removed.

#3 Updated by Gianluca Petrillo about 6 years ago

  • % Done changed from 0 to 100

#4 Updated by Gianluca Petrillo about 6 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF