On Tuesday, 9 September 2014 at 19:38:16 UTC, Robert burner Schadek wrote:
>> Also x-post from GitHub PR of my personal nitpick:
>>
>> "... have noticed that all logging functions have file/line/function data as template parameters. This will create insane symbol bloat. While I can understand desire to use some nicer variadic argument API providing at least one log function that it simplistic but moves all compile-time data to run-time default argument is absolutely necessary for me to consider this viable."
>
> I do not consider that a problem. The benefit is much higher than the cost of the bigger binary. This has already been a long conversation on some previous thread.

This unfortunately makes it almost unusable in absence of --gc-sections supporting compiler for lower level domains. Probably I am missing some data though, can you link the discussion thread? This PR dicussion is so long now that it hangs my browser when uncollapsing threads :(

On Saturday, 6 September 2014 at 19:41:54 UTC, Kevin Lamonte wrote:
> On Wednesday, 3 September 2014 at 13:13:31 UTC, Ola Fosheim Grøstad wrote:

> Since we are talking about performance, I did some tests and found to my surprise that ~95% of the time consumed in a log call is Clock.currTime's call to clock_gettime().  I submitted a report for it (https://issues.dlang.org/show_bug.cgi?id=13433), but it also brings up how to expose it in the std.logger API.

that is with all likelihood a syscall, so there goes your performance

>
> The API automatically grabs thisTid and Clock.currTime during construction of the LogEntry (plus it should also grab Thread.getThis and Fiber.getThis).  Should this behavior be modifiable by clients, by subclasses, or neither?  If so, how?

yes, I will move some of it into beginLogMsg

On 9/9/14, 12:38 PM, Robert burner Schadek wrote:
> On Saturday, 30 August 2014 at 02:18:30 UTC, Dicebot wrote:
>> "... have noticed that all logging functions have file/line/function
>> data as template parameters. This will create insane symbol bloat.
>> While I can understand desire to use some nicer variadic argument API
>> providing at least one log function that it simplistic but moves all
>> compile-time data to run-time default argument is absolutely necessary
>> for me to consider this viable."
>
> I do not consider that a problem. The benefit is much higher than the
> cost of the bigger binary. This has already been a long conversation on
> some previous thread.

There may be a miscommunication here. In short:

void fun(int x, string f = __FILE__)(double y);

can be replaced with:

void fun(int x)(double y, string f = __FILE__);

Both work and the second produces fewer instantiations.


Andrei

On Wednesday, 10 September 2014 at 07:41:49 UTC, Andrei Alexandrescu wrote:
> There may be a miscommunication here. In short:
>
> void fun(int x, string f = __FILE__)(double y);
>
> can be replaced with:
>
> void fun(int x)(double y, string f = __FILE__);
>
> Both work and the second produces fewer instantiations.
>
>
> Andrei

But

void fun(int l = __LINE__, A...)(A...); cannot be replaced by
void fun(A...)(A..., int l = __LINE__);

anyway thanks for reading and for trying to help

On Wednesday, 10 September 2014 at 08:47:47 UTC, Robert burner Schadek wrote:
> But
>
> void fun(int l = __LINE__, A...)(A...); cannot be replaced by
> void fun(A...)(A..., int l = __LINE__);
>
> anyway thanks for reading and for trying to help

And this is why I am asking for separate `logRaw` overload that takes pre-formatted string, for those who care.

On 10/09/14 10:47, Robert burner Schadek wrote:

> But
>
> void fun(int l = __LINE__, A...)(A...); cannot be replaced by
> void fun(A...)(A..., int l = __LINE__);

Could we modify the compiler to allow that? Just for the special identifiers __LINE__, __FILE__ and similar. It wouldn't be possible to specify a value for that parameter then.

-- 
/Jacob Carlborg

On Wednesday, 10 September 2014 at 11:39:52 UTC, Jacob Carlborg wrote:
> On 10/09/14 10:47, Robert burner Schadek wrote:
>
>> But
>>
>> void fun(int l = __LINE__, A...)(A...); cannot be replaced by
>> void fun(A...)(A..., int l = __LINE__);
>
> Could we modify the compiler to allow that? Just for the special identifiers __LINE__, __FILE__ and similar. It wouldn't be possible to specify a value for that parameter then.

IMO that is overkill, adding another another method that only takes one string as parameter is fine here

On Wednesday, 10 September 2014 at 11:39:52 UTC, Jacob Carlborg wrote:
> On 10/09/14 10:47, Robert burner Schadek wrote:
>
>> But
>>
>> void fun(int l = __LINE__, A...)(A...); cannot be replaced by
>> void fun(A...)(A..., int l = __LINE__);
>
> Could we modify the compiler to allow that? Just for the special identifiers __LINE__, __FILE__ and similar. It wouldn't be possible to specify a value for that parameter then.

This is much desired compiler enhancement in my opinion (this template instance bloat is really bad as it impacts not only symbol bloat but also compile times) but trying to get something that works right here and now.

On Wednesday, 10 September 2014 at 12:14:09 UTC, Dicebot wrote:
>
> This is much desired compiler enhancement in my opinion (this template instance bloat is really bad as it impacts not only symbol bloat but also compile times) but trying to get something that works right here and now.

killing this special overload, once the compiler does this, should be completely transparent

"Jacob Carlborg"  wrote in message news:lupda8$nl1$1@digitalmars.com... 

> Could we modify the compiler to allow that? Just for the special identifiers __LINE__, __FILE__ and similar. It wouldn't be possible to specify a value for that parameter then.

IIRC Andrei has a bugzilla open for this.