Disappointing performance from DMD/Phobos

[Basile B.]

On Tuesday, 26 June 2018 at 02:20:37 UTC, Manu wrote:
> On Mon, 25 Jun 2018 at 19:10, Manu <turkeyman at gmail.com> wrote:
>>
>> Some code:
>> ---------------------------------
>> struct Entity
>> {
>>   enum NumSystems = 4;
>>   struct SystemData
>>   {
>>     uint start, length;
>>   }
>>   SystemData[NumSystems] systemData;
>>   @property uint systemBits() const { return 
>> systemData[].map!(e =>
>> e.length).sum; }
>> }
>> Entity e;
>> e.systemBits(); // <- call the function, notice the codegen
>> ---------------------------------
>>
>> This property sum's 4 ints... that should be insanely fast. It 
>> should
>> also be something like 5-8 lines of asm.
>> Turns out, that call to sum() is eating 2.5% of my total perf
>> (significant among a substantial workload), and the call tree 
>> is quite
>> deep.
>>
>> Basically, inliner tried, but failed to seal the deal, and 
>> leaves a call stack 7 levels deep.
>>
>> Pipeline programming is hip and also *recommended* D usage. The
>> optimiser must do a good job. This is such a trivial workloop, 
>> and
>> with constant length (4).
>> I expect 3 integer adds to unroll and inline. A call-tree 7 
>> levels
>> deep is quite a ways from the mark.
>>
>> Maybe this is another instance of Walter's "phobos begat 
>> madness" observation?
>> The unoptimised callstack is mental. Compiling with -O trims 
>> most of
>> the noise in the call tree, but it fails to inline the 
>> remaining work
>> which ends up 7-levels down a redundant call-tree.
>
> I optimised another major gotcha eating perf, and now this 
> issue is taking 13% of my entire work time... bummer.

The inliner bug is that nested types are not hanlded.
And here is the relevant issue:

https://run.dlang.io/is/tVYrh9
https://issues.dlang.org/show_bug.cgi?id=16360

Even `static` struct inside (no context ptr) are enough to bug 
the inliner.
Bye bye voldemort types, see ya.