Project

General

Profile

Feature #4655

Possible performance enhancement to Fragment

Added by Marc Paterno about 7 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
09/18/2013
Due date:
04/25/2014
% Done:

0%

Estimated time:
40.00 h
Experiment:
Co-Assignees:
Duration: 220

Description

Fragment uses an underlying std::vector<RawDataType>. Some profiling has demonstrated that the constructor of Fragment which allocates a given size for the vector spends most of its time (>49% of the program time, for the test program s_r_handles) zeroing the elements of the vector. If it is true that these data do not need to be zeroed (we have not verified that leaving the values uninitialized is safe), then it may be beneficial to replace the std::vector by an class that contains an array of uninitialized RawDataType values, and whatever other data are necessary to make Fragment work.

This change is non-trivial because of the number of member functions of vector that are used in the implementation of Fragment. Many of these are used to implement the "metadata"-related functions of the Fragment class.

The time estimate for this enhancement includes creating the minimal class that will allow Fragment to work without changing the interface of Fragment. The resulting change in Fragment is likely to break backwards compatibility of data files; if this is necessary to fix, it is not clear how much additional time would be necessary.


Related issues

Related to ds50daq - Feature #4530: Memory pool(s) for art and artdaq?Closed08/11/2013

History

#1 Updated by Kurt Biery over 6 years ago

  • Due date set to 04/25/2014
  • Status changed from New to Assigned
  • Assignee set to Ron Rechenmacher
  • Target version set to v1_06_00
  • Estimated time changed from 16.00 h to 40.00 h

Ron,
This is the issue that you have been investigating with artdaq::Fragment (e.g. using the std::vector reserve method rather than resize). I'm assigning it to you so that we can better track its status.

It is related to Issue #5747 that John is working on to add methods that specify sizes in bytes.

Please let me know if you have any questions.
Thanks,
Kurt

#2 Updated by Kurt Biery over 6 years ago

I should have said that the original notes from Marc may be a little out-of-date based on developments that have occurred in the meantime...

#3 Updated by Kurt Biery over 6 years ago

  • Target version changed from v1_06_00 to v1_09_00

#4 Updated by Kurt Biery over 6 years ago

  • Target version changed from v1_09_00 to 575

#5 Updated by Kurt Biery about 6 years ago

  • Target version changed from 575 to v1_12_03

The bulk of the changes for this are available in artdaq_core v1_04_00 and artdaq v1_12_02. Some additional minor changes (e.g. naming) will be released soon.

#6 Updated by Kurt Biery over 5 years ago

  • Status changed from Assigned to Closed

This has been working successfully for some time now.

Also available in: Atom PDF