profiling issues

Vlad Levenfeld via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Thu Sep 11 20:23:54 PDT 2014


I've got a library I've been building up over a few projects, and 
I've only ever run it under "debug" "unittest" and "release" 
(with dub "buildOptions").
Lately I've needed to control the performance more carefully, but 
unfortunately trying to compile with dub --profile gives me some 
strange errors:

1) A few lines in one of my modules are reported as "unreachable" 
by dmd. The data they operate on are defined entirely in code 
(i.e. not read as external input) so maybe they're getting CTFE'd 
into oblivion?
All I know is they're apparently reachable in non-profiled code 
(and very essential to the business logic... but they're just 
math functions, nothing crazy, one of the unreachable lines 
computes the areas of some polygons, another sums the areas up).

2) The linker complains about undefined references to 
std.exception.enforce being called from std.stdio.rawRead.

3) If I try to compile with "buildOptions":["profile"] instead of 
dub --profile, then it compiles and links but then I segfault on 
launch at gc_malloc.

I also recall (but can't seem to find) something about profiling 
not working with multithreaded code? Because almost every 
encapsulated service in this library runs on its own thread.

And the code base (>15k LOC) isn't easily reduced, as any 
remotely interesting main method I write pretty much pulls from 
the entire library. I don't want to have to turn this whole thing 
inside out. Its like 95% templates and inlining wreaks havoc on 
the logic as well, but that's another problem for another day...

Does anyone else have these kinds of issues? Are there any 
alternative methods of coarse-grained profiling (i.e., not 
manually peppering timer calls into my code)? Whats with the 
unreachable statements? Any hints on what I can try next to get 
closer to a performance profile of my code?


More information about the Digitalmars-d-learn mailing list