[SAoC] 'DPP with Linux kernel headers' Project Thread

[Cristian Becerescu]

Update for week 3 of Milestone 3

- Fixed an issue which deals with the way nested aggregates are 
used outside of their parent (enclosing) aggregate

e.g.:

struct A {
     struct B {
         int a;
         int c;
     } b_obj;
     int other;
};

void f(struct B*); // works in C, in D it should be A.B (but it 
was still translated to just B)
// Also applicable to field types

A better explanation and an actual solution are presented in the 
PR below.
PR: https://github.com/atilaneves/dpp/pull/226

- Did some profiling on DPP with lots of kernel header files 
included in the same .dpp file.
Memory usage after libclang finishes parsing: 300MB.
Memory usage after DPP finishes processing the AST provided by 
libclang: 6-7GB (this is where some fishy things happen).
DPP then tries to use 'cpp' on the .d.tmp file for C 
preprocessing, but the process spawning fails, as there is not 
enough memory left to fork and execute (I was testing on an 8GB 
machine).

It turns out (and huge thanks to Edi and Razvan for your help 
with this) that the Appender object  '_lines' (which stores the 
strings to be written in the translated D file) leaks memory. 
This was apparently an already known issue: 
https://issues.dlang.org/show_bug.cgi?id=19511

I've changed the type from Appender to built-in array and the 
maximum memory usage at any point is somewhere between 2.0-2.4GB, 
way better than 7GB :)

Edi also wrote a simple test and it seems that for appending ~ 
10^6 strings of length 20 each, Appender is just 20ms faster. I 
also tested this with headers generating a 250K line (850K words 
total) D file and performance doesn't differ (I also think that 
as long as Appender is leaking it shouldn't be used no matter the 
speed boost, considering the large C codebases that DPP could be 
used with).
PR: https://github.com/atilaneves/dpp/pull/227