Possible performance enhancement to Fragment
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.
#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
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.