67 – Imported functions are not inlined.

/*
 Compile with -O -inline -release
 This program compares performance of 2 identical functions, one inlined,
 the other not.
 There is about a 7x difference on my system.
*/
import std.stdio, std.date, std.math;
// local copy of std.math.abs()
int abs(int x)
{
return x >= 0 ? x : -x;
}
void main()
{
 int sum = 0;
 d_time s = getUTCtime();
 for(int i = 0; i < 100_000_000; i++)
 {
 sum += std.math.abs(i);
 sum -= std.math.abs(-i);
 }
 d_time e = getUTCtime();
 writefln("std.math.abs(): sum= ",sum,", secs = ",(e - s)/cast(double)TicksPerSecond);
 d_time tmp = e - s;
 sum = 0;
 s = getUTCtime();
 for(int i = 0; i < 100_000_000; i++)
 {
 sum += .abs(i);
 sum -= .abs(-i);
 }
 e = getUTCtime();
 writefln("local abs(): sum= ",sum,", secs = ",(e - s)/cast(double)TicksPerSecond);
 writefln("ratio = ", tmp / cast(double)(e - s));
}

That's because in inline.c, when checking to see if a function can be inlined, it checks to see if the semantic run has happened yet. Which makes sense, because that needs to happen to inline it.
Simply adding a semantic3 to Import fixes this (because then imported functions are get a sematic run), although honestly I'm not sure if that's the right fix. It may be a lot slower to do this, and it may certainly have been left out on purpose.
Maybe it can be sematic3'd only when -inline is passed, if that can work.
Really, I must say, I always expected that this worked and now wonder how much benefit/deteriment it would give if it did.
Thanks,
-[Unknown]

>That's because in inline.c, when checking to see if a function can be inlined,
>it checks to see if the semantic run has happened yet. Which makes sense,
>because that needs to happen to inline it.
>
>Simply adding a semantic3 to Import fixes this (because then imported functions
>are get a sematic run), although honestly I'm not sure if that's the right fix.
Good catch! I'll try and find the time to update my copy of the dmd front-end and give it a shot. Given D is performance orientated, this needs to work as people will expect it to.
> It may be a lot slower to do this, and it may certainly have been left out on
>purpose.
Yea, but in any case -inline doesn't have to be used and won't be for most of the code/debug/run cycle, right? The DMD compiler is so fast that even for release builds I can't see this causing a big problem requiring things like "grid compiling" <g>.
If code size is a concern, most of phobos.lib is built w/o -inline right now, and again, it doesn't have to be used if it severly bloats the code. Sometimes inlining can even reduce code size.
>
>Maybe it can be sematic3'd only when -inline is passed, if that can work.
>
If that is the solution, then it shouldn't be a problem to implement because the compiler switches are global.
Hmmm - could semantic3 just be run in inline.c if it has not been run yet (as in the case of an imported function)? In any case the import and it's contents will have already had semantic() run during the 1st semantic pass because Import::semantic() calls Module::semantic() to process all the symbols in that module, including other imports, so semantic() is always done recursively before the inline pass. So, those functions should be ready for semantic3() before the inline pass... Cool!
If the fix is really that easy then there is no reason not to fix this right away. The worst that could happen is that it will flush out problems with -inline that people will eventually encounter anyhow so the sooner the better I think.
>
>Really, I must say, I always expected that this worked and now wonder how much
>benefit/deteriment it would give if it did.
>
It can make a very big difference for some pretty commonly used imported functions, and it'll be expected by users of every other language that inlines. 
I have not run into a case where it makes any executable slower and can't imagine it being a detriment except in the potential/odd case where it does severly bloat the code.
Thanks,
- Dave
>Thanks,
>-[Unknown]

Righto. I didn't spend much time on it, but it would have been nice if 
there was some indication in the bugzilla bug that it was fixed.
Do we have anyone who is expected to verify bugs? Typically, from all 
the bugzilla's I've worked with, bugs are marked fixed and, ideally, 
verified (or reopened) as such by QA before a release is made.
Maybe this is too much red tape, but it would seem logical to QA the 
bugs after releases, at least. IMHO.
Thanks,
-[Unknown]
> Don't spend time on this bug, I already have it fixed. -Walter 
> 
> 

Walter Bright wrote:
> "Unknown W. Brackets" <unknown@simplemachines.org> wrote in message 
> news:e04325$fr81ドル@digitaldaemon.com...
>> Maybe this is too much red tape, but it would seem logical to QA the bugs 
>> after releases, at least. IMHO.
> 
> Thomas has been doing a great job with that. 
> 
> 
Really! I think Thomas doesn't get enough love around here. Way to go man, you are always snapping up those cases for the test 
suite, and it make a huge difference. Thanks for your work.

This has been fixed since DMD 0.151.