Overhead of DIP1036

[Hipreme]

On Wednesday, 10 January 2024 at 20:19:46 UTC, Walter Bright 
wrote:
> On 1/9/2024 3:33 PM, Steven Schveighoffer wrote:
>> I find it bizarre to be concerned about the call performance 
>> of zero-sized structs and empty strings to writeln or writef, 
>> like the function is some shining example of performance or 
>> efficient argument passing. If you do not have inlining or 
>> optimizations enabled, do you think the call tree of writefln 
>> is going to be compact? Not to mention it eventually just 
>> calls into C opaquely.
>> 
>> Note that you can write a simple wrapper that can be inlined, 
>> which will mitigate all of this via compile-time 
>> transformations.
>> 
>> If you like, I can write it up and you can try it out!
>
> I've been aware for a long time that writeln and writefln are 
> very inefficient, and could use a re-engineering.
>
> A big part of the problem is the blizzard of templates 
> resulting from using them. This issue doubles the number of 
> templates. Even if they are optimized away, they sit in the 
> object file.
>
> Anyhow, see my other reply to Timon. I may have found a 
> solution. I'm interested in your thoughts on it.

Are you sure you really want to keep optimizing debug logging 
functionality? Come on. The only reason to keep using `printf` 
and `writeln` is for debug logging. If you're going to show your 
log function to a user, it is going to be completely different.

They are super easy to disable by simply creating a wrapper.
If you want to know what increases the compilation time on them, 
is `std.conv.to!float`. I have said this many times on forums 
already. I don't know about people's hobby, but caring about 
performance on logging is simply too much.

Do me a favor: Press F12 to open your browser's console, then 
write at it: `for(let i = 0; i < 10000; i ++) console.log(i);`

You'll notice how slot it is. And this is not JS problem. Logging 
is always slow, no matter how much you optimize. I personally 
find this a great loss of time that could be directed into a lot 
more useful tasks, such as:
- Improving debugging symbols in DMD and for macOS
- Improving importC until it actually works
- Listen to rikki's complaint about how slow it is to import UTF 
Tables
- Improving support for shared libraries on DMD (like not making 
it collect an interfaced object)
- Solve the problem with `init` property of structs containing 
memory reference which can be easily be corrupted
- Fix the problem when an abstract class implements an interface
- Make a D compiler daemon
- Help in the project of DMD as a library focused on helping 
WebFreak in code-d and serve-d
- Implement DMD support for Apple Silicon
- Revive newCTFE engine
- Implement ctfe caching


Those are the only thing I can take of my mind right now. Anyway, 
I'm not here to demand anything at all. I'm only giving examples 
on what could be done in fields I have no experience in how to 
make it better, but I know people out there can do it. But for 
me, it is just a pity to see such genius wasting time on 
improving a rather antiquated debug functionality