H. S. Teoh wrote:

> Having said all that, though, have you used a profiler to determine
> whether or not your performance bottleneck is really at the function in
> question?  I find that 90% of the time what I truly believe should be
> inlined actually doesn't make much difference; the bottleneck is usually
> somewhere else that I didn't expect.  I used to spend lots of time
> trying to hyper-optimize everything, only to discover later that 90% of
> my efforts have been wasted on gaining a meager 1% of performance,
> whereas if I had just used a profiler in the first place, I would have
> gotten a 50% performance improvement with only 10% of the effort.
hear, hear!

On Monday, 20 February 2017 at 13:16:15 UTC, Jonathan M Davis wrote:
> dmd is great for fast compilation and therefore it's great for development. However, while it produces decent binaries, and it may very well do certain optimizations better than the gcc or llvm backends do

This I find hard to believe. Do you have an example where DMD generates faster code than GDC or LDC ?

Thanks,
  Johan

Dne 21.2.2017 v 08:31 Johan Engelen via Digitalmars-d-learn napsal(a):

> On Monday, 20 February 2017 at 13:16:15 UTC, Jonathan M Davis wrote:
>> dmd is great for fast compilation and therefore it's great for development. However, while it produces decent binaries, and it may very well do certain optimizations better than the gcc or llvm backends do
>
> This I find hard to believe. Do you have an example where DMD generates faster code than GDC or LDC ?
>
> Thanks,
>   Johan
I remember there has been some. One has been a problem with loop elimination, where ldc was not able to remove some of loops which does not do anything and dmd was, but I believe it has been fixed now.

Dne 21.2.2017 v 08:41 Daniel Kozak napsal(a):

> Dne 21.2.2017 v 08:31 Johan Engelen via Digitalmars-d-learn napsal(a):
>
>> On Monday, 20 February 2017 at 13:16:15 UTC, Jonathan M Davis wrote:
>>> dmd is great for fast compilation and therefore it's great for development. However, while it produces decent binaries, and it may very well do certain optimizations better than the gcc or llvm backends do
>>
>> This I find hard to believe. Do you have an example where DMD generates faster code than GDC or LDC ?
>>
>> Thanks,
>>   Johan
> I remember there has been some. One has been a problem with loop elimination, where ldc was not able to remove some of loops which does not do anything and dmd was, but I believe it has been fixed now.
>

http://forum.dlang.org/post/otlxsuticdpwqxzumhrs@forum.dlang.org
http://forum.dlang.org/post/qoxttndpotbpztwnqome@forum.dlang.org

On Monday, 20 February 2017 at 13:48:30 UTC, ketmar wrote:
> anyway, in my real-life code inlining never worth the MASSIVELY increased compile times: speedup is never actually noticeable. if "dmd -O" doesn't satisfy your needs, there is usually no reason to trying "-inline", it is better to switch to ldc/gdc.

Probably you're right. I'm using gdc anyway for non-developement compiles. I was just curious how much that -inline switch of dmd is worth. (Answer: Yet, almost nothing. And knowing, that it is buggy together with -O even less than that.)

When comparing dmd and gdc the results where both almost the same: 29 seconds. (As a reference: C++ is 22 seconds.) With gdc I got a good improvement when using -frelease additionally to -O3 (now it's 24 seconds). The inline-pragma didn't change anything.

On Monday, 20 February 2017 at 17:12:59 UTC, H. S. Teoh wrote:

> Having said all that, though, have you used a profiler to determine whether or not your performance bottleneck is really at the function in question?

Yes, I did. An well, yes I know: Good design is much more important, than speed optimization. And by obeying this, I found out, that by changing the order of the conditions used in that particular function, I could reduce the duration by 2 more seconds... (And in case you wonder, why I bother about 2 seconds: It's a small example for testing purpose. There are larger ones where this could easily be hours instead of seconds...)