From: dhenry on
Thank you for all your replies.

As Dmitry said, the log level may dynamically change. Therefore,
inlining in order to let the compiler do the optimization doesn't
work.

Neither is the "Tricky" procedure tip. The example I gave with a
"parameter name" stored in an unbounded string was just an
illustration of a complex string to log. But of course, it could be
any variable and of any type, for a lot of different sentences, so I
can't write a new procedure each time (I'd prefer writing the if-test
each time).

There may be no solution as I'd like. I'll prefer to let the
application perform a lot of useless string conversion and
concatenations rather have an optimized but heavy to use logging
system. (For the moment, I don't have serious performance issues so
that I would need to reduce those useless string operations).
From: Dmitry A. Kazakov on
On Tue, 18 May 2010 14:10:15 +0200, Georg Bauhaus wrote:

> On 18.05.10 12:26, Dmitry A. Kazakov wrote:
>
>> BTW, it could be a statement, e.g. conditional call:
>>
>> <procedure/entry-call> when <condition>;
>
> Wouldn't conditional expression work this way?
>
> Proc ((if Condition then This else That));

Yes, if we wanted to introduce a full-blown lazy evaluation in Ada. But
then I wished a better, lighter syntax and cleaner semantics.

procedure Write (Where : in out Log; Message : lazy String);

BTW, another case for lazy evaluation is controlling side effects and
evaluation order. E.g.

function Read (From : access Stream) return Byte;
function Read (From : access Stream) return Byte;
function "&" (Left : Byte_Array; Right : lazy Byte) return Byte_Array;

then:

X : Byte_Array := Read (S) & Read (S); -- This is unambiguous

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Jeffrey R. Carter on
stefan-lucks(a)see-the.signature wrote:
>
> package Flexi_Log is
>
> procedure Write(Log_Level: Log.Level_Type;
> Message_1: String := "";
> Message_2: String := "";
> Message_3: String := "";
> ...
> Message_9: String := "");
> -- if Log_Level>0 then
> -- Log.Write(Message_1 & Message_2 & ... , Log_Level);
> -- end if;
>
> end Flexi_Log;
>
> In any case, the number of different strings to make one message is
> constant. The constant is under your control, but it is constant. If your
> support goes for up to, say, Message_9, a message for the log which
> consists of 10 or more parts may still trouble you. So change the constant
> sufficiently large that it doesn't trouble you too often ...

You could also do something like:

type Message_List is array (Positive range <>) of Ada.Strings.Unbounded;

procedure Write (Level : Log.Level_ID; Message : Message_List);
-- If Level > No_Logging and Message'Length > 0 then log the concatenation of
-- the strings in Message.

But I don't see that it buys you much, if anything.

Ultimately, this sounds like a case of premature optimization, given that the
string operations are not impacting your timing requirements, according to
another post.

--
Jeff Carter
"You've got the brain of a four-year-old boy,
and I bet he was glad to get rid of it."
Horse Feathers
47
From: tmoran on
> In a language like C or C++, I would use the preprocessor:
> #define LOG(text, level) if (level > 0) { log.write (text, level) }
So write your own specialized preprocessor that adds the "if"
statement to calls on log.write before handing the result to the compiler.

> I'd like to avoid the string evaluation if the logging is disabled
> (because it consumes CPU resources).
As usual with "optimizations", the first question is "will this
obfuscation actually save significant time?". If the answer,
surprisingly, is "yes", then find the few places where log.write
is actually called millions of times and manually insert the "if"
test in those places.
From: dhenry on
On 18 mai, 20:40, tmo...(a)acm.org wrote:
>    So write your own specialized preprocessor that adds the "if"
> statement to calls on log.write before handing the result to the compiler..

That may be a possible solution to my problem.

>   As usual with "optimizations", the first question is "will this
> obfuscation actually save significant time?".  If the answer,
> surprisingly, is "yes", then find the few places where log.write
> is actually called millions of times and manually insert the "if"
> test in those places.

Yes, this may be seen as a premature optimization. I was just looking
for a possible opportunity (and maybe learn some new Ada tricks). If I
encounter some real performance issues, I'll probably do that.

I prefer something "elegant" (code readability and maintenance is
important) but with "poor" performances, as long as it respects
performance requirements.