Obtaining more information from Timing service
art provides a 'Timing' option for measuring the time spent in individual modules and/or events. The current implementation provides only cout printout, either once/module/event, or a summary (not module specific) at endjob. In order to analyze this data I have created an 'awk' script to analyze the non-summary data, finding the appropriate module by name, extract the data, and then create a file which can be read in by ROOT. It would be more convenient to have this data available in code. For example, if there were a boost::accumulator_set for each module, with tags mean, min, max, variance, ... those accumulators could get filled each event, and be made available through a Services interface to the endJob method, where the values could be extracted. This would also allow a module-by-module summary to be printed at endjob.
#1 Updated by Christopher Green about 7 years ago
- Due date set to 09/30/2013
- Category set to Infrastructure
- Status changed from New to Accepted
- Target version set to 1.09.00
- Estimated time set to 48.00 h
- Scope set to Internal
- Experiment Mu2e added
- SSI Package art added
This is an eminently reasonable request. We would prefer to put the information in an optionally-persisted SQLite database accessible by clients of the service, since we will be expanding that facility anyway. Would this be acceptable to you?
#4 Updated by Christopher Green about 7 years ago
From Dave Brown:
Does this mean SQLite becomes a required dependency for art? Will there be a code interface to this information during run-time in art, or will this only support after-job analysis?
SQLite has been a required dependency for a long time now. There is already a (very basic) code interface at run-time, but this will need refinement and fleshing-out.
#5 Updated by Rob Kutschke about 7 years ago
I suppose that, if we want to present the information as a data product, we could write a module that has only endRun behaviour, that interrogates the SQLite database and packages the information as a run-scope data product.
Dave: there is no such thing as a "file scope" data product but the SQLite data base can store file-scope information. There is a user interface to it but I have not used it yet.
#11 Updated by Kyle Knoepfel almost 6 years ago
- Status changed from Feedback to Resolved
- % Done changed from 0 to 100
In order to support users that depend on the current timing service printout format, we have retained
Timing_service.cc as a legacy service. A new timing service, however, has been developed -
TimeTracker_service.cc - that addresses the above issues. The new service is entirely
See the TimeTracker documentation for details.
Implemented with e7078a47887c46d97e977b05f4f985b0cc5b3aec.