D compiler profiling

Question

How to determine which part of my d code takes a long time to compile?

I tried to use valgrind, but the method names were not very insightful. 87% of the time was spent on <cycle 7> , 40% of the time in _D4ddmd5lexer5Lexer4scanMFPS4ddmd6tokens5TokenZv

I'm looking for something like this: 40% of the time was spent on xy.d , from the fact that 80% of the time was compiling different instances of the xyz template, and the reason is that it used memcpy 99% of the time.

I am interested in profiling both DMD and LDC.

Answer 1

Since the front end of the D compiler is written to D, profiling using conventional tools will be quite complicated compared to something like C ++. I have had some success using tools like gdb and valgrind for Linux, and tools like VisualD for Windows, Mac users are SOL.

You have five more options:

• Stop trying to find a specific function in the compiler and refer to the general knowledge of the problem (see below).
• Use a tool like https://github.com/CyberShadow/DBuildStat . It does not give you the exact answer you are asking about, but if you are trying to get a large project in order to compile it faster, nothing is better.
• Use the -v flag to try and see which parts of your program take some time. Of course, this is a very rude approach and may take some time.
• Modify the makefile on the DMD interface to use the -profile switch. Each time you run DMD, you will get a profile file with a lot of information. Of course, I don’t think it’s ever been tried. Your objection may vary.
• Try asking the LDC team about this on the Github problems page. IIRC they made a revised version for profiling, which they used for the code base Weka.io.

When I talk about general knowledge, I want to say that your slow compilation is probably related to several common problems. For example, when an SQL query takes too much time, my first reaction is not to try to profile the MySQL server code. Here are some common problems.

• CTFE, while speeding up execution time, slowly . Especially if you use recursive templates like allSatisfy , or your functions like ctRegex . If you are doing heavy CTFE and want to compile faster at the price of a slower code, consider switching them to runtime calls.
• DMD does not yet ignore characters that are not used in your program, which means that if you import a module, gen-code will be used for all functions of the module. This is true even for selective imports. If you do not use them, the linker will trim the functions from the resulting executable, but the compiler still takes time to compile them. Avoid imports, such as import std.algorithm; or import std.range; . Instead, use the import of specific packages, such as import std.algorithm.iteration : map; .