Skip to content

PFlow const correctness and MessageSvc conjestion fixes

In this MR

  • const correctness fixes in the helper classes
  • Also Move them to inheriting from asg::AsgMessaging
  • Make them members of the tool that uses them
  • As as result we do not initialize them per call. But only in the initialize of the tool
  • The last should get rid of too many calls for setting the message service, locking bottleneck

Further discussion

@mhodgkin you need to decide

A. Do you want to change the behaviour of the code and NOT have messages in release build ?

  • If the answer is no. Meaning you still want messages, in rel via config with no re-compilation (What the code was doing up to now), then this is one way (4) the other is (6).

  • If the answer is yes . You want these messages only given a recompilation from the developer. Then go with something else (2),(5),(7 @goetz [!52061 (closed)] ) or (8) completely remove these (what I would have done in this case)

List of options 7 from @goetz, 8th from me

1 .ignore and live with the bottlenecks

2 .put ifdefs around everything that should not be in the opt build

  1. turn the helper classes into full fledged reentrant tools
  1. just make the helper classes reentrant and make them members
  1. replace the ATH_MSG with cout and put ifdefs around
  1. use the message infrastructure from the parent algorithm
  1. introduce this base class which mimics the ATH_MSG which makes the overhead compile time optional
  1. Remove these messages do not help really someone that much.

And yes obviously having messaging enabled in release builds without recompilation appears in the assembly. This is the obvious bit (but since we like to comment on these for some "profound" reason let me write it). Btw this is why (it is there in assembly) I am in favour of NO / 0 messaging if is only for personal developer "debug printout during recompilation cycles" and have no other "functional"/0 purpose i.e 8.

Edited by Christos Anastopoulos

Merge request reports