Debug flags

[AndersenFred]

Starting guarding all debug messages via

#ifdef __GENIE_LOW_LEVEL_MESG_ENABLED__
  LOG(...,pDEBUG)<< Message;
#endif

as at some point, my log exploded to something like 80GB.
This potentially could also improve (slightly) performance.

[nusense]

Yike, Ah, I don't think we want this modification. The messenger service has different "streams" and "priorities":

   The priority (in descending importance order) can be
    FATAL, ALERT, CRIT, ERROR, WARN, NOTICE, INFO, DEBUG

And each stream can be controlled by an entry in the Messenger XML file (default is $GENIE/config/Messenger.xml). For most applications this default can be overridden by supplying an alternative file and telling the app to use that file.

There exist some predefined alternative configurations: Messenger_laconic.xml, Messenger_rambling.xml and Messenger_whisper.xml , or you can use one of those as a template for your own. For streams that aren't listed in the XML file I believe the default priority is pINFO (tested this). If there's a stream that needs an entry, one should add it to all of the 4 existing files at an appropriate priority. If it exists and you got too many messages, either the particular instance needs a lower priority in the code, or a higher priority in the XML file.

Generally the code isn't built on most sites with __GENIE_LOW_LEVEL_MESG_ENABLED__ so bracketing the logging messages with that defeats the purpose of priorities by disallowing the message from being enabled. The overhead of the Message service isn't very onerous except in very, very tight loops that are repeated frequently. Not all pDEBUG messages need to be in the #ifdef/#endif

I'm very surprised that you got 80 GB of messages unless you somehow enabled that priority for that stream.

[AndersenFred]

On the one hand yes, but every log costs time and a lot of these messages are clearly for debugging and do not contain useful information for the user. I will revise the messages, but I would recommend at least to guard log in parts that get called verry often and do not contribute much.

The 80 GB happens after setting splines and something false to debug.