digitalmars.D.learn - D is supposed to compile fast.
- Chris Katko (19/19) Nov 23 2018 Any time I see people mention the benefits of D, I see "compile
- Nicholas Wilson (14/33) Nov 23 2018 If you pass all the files on the command line then they all get
- Chris Katko (36/38) Nov 24 2018 How are you supposed include files if not passing them to the
- H. S. Teoh (12/22) Nov 24 2018 [...]
- Daniel Kozak (4/23) Nov 23 2018 AFAIK debug builds are slower? Can you share your files with us? So I ca...
- Stefan Koch (4/7) Nov 23 2018 If you can share the code privately I can use my custom profiling
- H. S. Teoh (29/41) Nov 23 2018 D is extremely fast at compilation ... of C-like code. :-D
- Adam D. Ruppe (13/14) Nov 23 2018 Merely importing a Phobos module is liable to cost you a quarter
- H. S. Teoh (24/38) Nov 23 2018 Yes, I'm aware of that. It used to be the case that the mere importing
- Jonathan M Davis (22/28) Nov 23 2018 When I was a student, I worked for a while at a company that had a large...
- welkam (4/5) Nov 24 2018 You didnt read the fine print. It compiles simple code fast. Also
- Chris Katko (108/113) Nov 25 2018 Wait wait wait wait wait.
- Tony (5/16) Nov 25 2018 "runs the files every time"? If that means "compiles the files
- Mike Parker (38/78) Nov 25 2018 cmake doesn't actually build anything. It generates make files or
- aliak (15/22) Nov 26 2018 I thought people had reached that point already:
- welkam (28/57) Nov 26 2018 Well you dont have to use separate commands but yes compiling and
- Stefan Koch (15/34) Nov 26 2018 I've profiled your example, unsurprisingly allmost all of the
Any time I see people mention the benefits of D, I see "compile times" "compile times" "compile times" over and over. I'm using very modest amounts of templates, for a fairly small sized program (very early work toward a game), and I'm hitting ~15 seconds compile time in LDC and ~7 seconds in DMD. And I'm not even compiling with optimizations! ldc2 -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -L-L. $ -gc -d-debug=3 -de -fdmd-trace-functions dmd -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -profile=gc -profile -g -debug -color -L-L. I keep putting stuff into new files, but it feels like it's compiling everything from scratch / not getting faster the way C++ does. And I'm not even bringing up the 800MB of RAM required because I dared to import std.regex. (On a laptop with 2 GB of RAM. RIP. If I dare to have tabs open, the compile time goes into the minutes thanks to swapping.)
Nov 23 2018
On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:Any time I see people mention the benefits of D, I see "compile times" "compile times" "compile times" over and over. I'm using very modest amounts of templates, for a fairly small sized program (very early work toward a game), and I'm hitting ~15 seconds compile time in LDC and ~7 seconds in DMD. And I'm not even compiling with optimizations!Templates are slow, slower than CTFE.ldc2 -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -L-L. $ -gc -d-debug=3 -de -fdmd-trace-functions dmd -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -profile=gc -profile -g -debug -color -L-L. I keep putting stuff into new files, but it feels like it's compiling everything from scratch / not getting faster the way C++ does.If you pass all the files on the command line then they all get (re)compiled. Have separate rules for each file, although if you are using template from each file in every file that may not help a whole lot.And I'm not even bringing up the 800MB of RAM required because I dared to import std.regex. (On a laptop with 2 GB of RAM. RIP. If I dare to have tabs open, the compile time goes into the minutes thanks to swapping.)Yep, on the upside the regexen are very fast at runtime. std.regex depending on how much of it you are using could also be a cause of your problem.you might want to take a look at https://blog.thecybershadow.net/2018/02/07/dmdprof/ https://github.com/CyberShadow/dmdprof to see whats taking so long Is this code online? Its a bit difficult to give specific advice without it.
Nov 23 2018
On Friday, 23 November 2018 at 10:00:17 UTC, Nicholas Wilson wrote:If you pass all the files on the command line then they all get (re)compiled.How are you supposed include files if not passing them to the compiler? I'm only using std.regex in one file, IIRC, so whatever the "proper" way to only compile changed files should improve it drastically. Almost all of my templates are incredibly simple like using generic arguments for taking float and doubles, instead of hardcoded float. I am using both Allegro and DAllegro (a D binding for Allegro5). But until recently, the compile times have been very fast. So it's definitely been D features cutting things down. And as for "compile-time doesn't matter" arguments, that's plain silly. I'm not a junior programmer. I've had builds that took over 30 minutes to compile and as we all (should!) know, the longer the build time (especially over 10 seconds), the quicker the mind loses its train-of-thought and the more difficulty the brain has with establishing cause-and-effect relationships between code and bugs. When our builds hit 30 minutes, we ended up so disconnected from the project we'd end up playing a short game of Duke Nukem 3-D inbetween builds. (Ha! Builds. Build engine = the Duke Nukem 3D engine. A super-niche pun.) We were incredibly unproductive until I re-wrote the entire thing in a different language. It ran in less than 10 seconds and suddenly we were powering through new problem after new problem. (A huge data conversion project between a discontinued, no-documentation product and a new product by a different company.) Anyhow, if you REALLY want to look at some very WIP code with poor documentation and possibly lots of random swearing (hobby project for trying out D in a game), I'll make the repo public for now: https://bitbucket.org/katasticvoyage/ss14/src/master/ extra.d is a main code unit for this application. ini.d has regex. (and no, it's not a proper lexer. I'm probably swapping it out with JSON.)
Nov 24 2018
"H. S. Teoh" <hsteoh quickfur.ath.cx> On Sat, Nov 24, 2018 at 09:20:08AM +0000, Chris Katko via Digitalmars-d-learn wrote:On Friday, 23 November 2018 at 10:00:17 UTC, Nicholas Wilson wrote:[...] Use separate compilation: dmd -c module1.d dmd -c module2.d ... dmd module1.o module2.o ... -of/usr/bin/myprogram Put this in a makefile or your build system of choice, and let it do incremental builds. T -- Государство делает вид, что платит нам зарплату, а мы делаем вид, что работаем.If you pass all the files on the command line then they all get (re)compiled.How are you supposed include files if not passing them to the compiler? I'm only using std.regex in one file, IIRC, so whatever the "proper" way to only compile changed files should improve it drastically.
Nov 24 2018
On Fri, Nov 23, 2018 at 10:00 AM Chris Katko via Digitalmars-d-learn < digitalmars-d-learn puremagic.com> wrote:Any time I see people mention the benefits of D, I see "compile times" "compile times" "compile times" over and over. I'm using very modest amounts of templates, for a fairly small sized program (very early work toward a game), and I'm hitting ~15 seconds compile time in LDC and ~7 seconds in DMD. And I'm not even compiling with optimizations! ldc2 -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -L-L. $ -gc -d-debug=3 -de -fdmd-trace-functions dmd -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -profile=gc -profile -g -debug -color -L-L. I keep putting stuff into new files, but it feels like it's compiling everything from scratch / not getting faster the way C++ does. And I'm not even bringing up the 800MB of RAM required because I dared to import std.regex. (On a laptop with 2 GB of RAM. RIP. If I dare to have tabs open, the compile time goes into the minutes thanks to swapping.)AFAIK debug builds are slower? Can you share your files with us? So I can try to find out what is the main problem
Nov 23 2018
On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:Any time I see people mention the benefits of D, I see "compile times" "compile times" "compile times" over and over. [...]If you can share the code privately I can use my custom profiling build of dmd to analyze the problem. just send me a mail (uplink{dot}coder{at}gmail{dot}com)
Nov 23 2018
On Fri, Nov 23, 2018 at 08:57:57AM +0000, Chris Katko via Digitalmars-d-learn wrote:Any time I see people mention the benefits of D, I see "compile times" "compile times" "compile times" over and over.D is extremely fast at compilation ... of C-like code. :-D Anything involving heavy use of templates and/or CTFE will quickly slow things down, sometimes by a lot.I'm using very modest amounts of templates, for a fairly small sized program (very early work toward a game), and I'm hitting ~15 seconds compile time in LDC and ~7 seconds in DMD. And I'm not even compiling with optimizations!Are you using template-heavy Phobos functions? Some parts of Phobos are known to be extremely slow, e.g., std.format (which is indirectly imported by std.stdio), due to the sheer amount of templates it uses. [...]I keep putting stuff into new files, but it feels like it's compiling everything from scratch / not getting faster the way C++ does.Are you still compiling everything in one command, or separately compiling? There's not much point (as far as compile times are concerned) in splitting up into new files if you're still compiling everything each time.And I'm not even bringing up the 800MB of RAM required because I dared to import std.regex. (On a laptop with 2 GB of RAM. RIP. If I dare to have tabs open, the compile time goes into the minutes thanks to swapping.)Yeah, std.regex is known to be pretty nasty in terms of compile times / memory usage, because its internals uses a LOT of templates. There have been efforts to fix / improve this, but I haven't kept up with the developments, so I'm not sure where things are at now. One caveat about std.regex, though: you may actually want to use runtime regexen instead of ctRegex, in spite of the supposed performance improvements; I recall reading somewhere that ctRegex actually isn't as fast as you might think, yet it comes at a HUGE compile-time cost (and I do mean HUGE... it can significantly increase compile times for only marginal or sometimes even negative runtime performance -- because of template bloat). I've stopped using ctRegex altogether and just been initializing regexen with `static this()` instead. Or sometimes even just pure runtime regexen, because the cost of initializing once is insignificant compared to subsequent repeated usage. T -- Too many people have open minds but closed eyes.
Nov 23 2018
On Friday, 23 November 2018 at 17:21:46 UTC, H. S. Teoh wrote:Are you using template-heavy Phobos functions?Merely importing a Phobos module is liable to cost you a quarter second or more of compile time. I just got my gui lib (22,000 lines of raw source, dscanner -sloc reports 12,000) compiling in 0.2s on Linux, down from 1.0s, by removing ALL the phobos imports. It is 0.6s on Windows, probably because it imports so many of the Windows headers. I like to say C style and Java style code compiles really fast... but you wanna beware of imports of the standard library, since it brings in a LOT of code, some of which is really slow to run (parts of it are slower than others, like std.algorithm is actually pretty fast to compile+use, but std.regex is brutally slow)
Nov 23 2018
On Fri, Nov 23, 2018 at 05:37:46PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:On Friday, 23 November 2018 at 17:21:46 UTC, H. S. Teoh wrote:Yes, I'm aware of that. It used to be the case that the mere importing of std.format would add 2-3 seconds to your compile time, but I think the worst of it has been fixed. It's still not cheap to use std.format, but it's improved from what it used to be.Are you using template-heavy Phobos functions?Merely importing a Phobos module is liable to cost you a quarter second or more of compile time.I just got my gui lib (22,000 lines of raw source, dscanner -sloc reports 12,000) compiling in 0.2s on Linux, down from 1.0s, by removing ALL the phobos imports. It is 0.6s on Windows, probably because it imports so many of the Windows headers.Yeah, I find that avoiding certain Phobos modules like std.format or std.regex really does help a lot in improving compile times.I like to say C style and Java style code compiles really fast... but you wanna beware of imports of the standard library, since it brings in a LOT of code, some of which is really slow to run (parts of it are slower than others, like std.algorithm is actually pretty fast to compile+use, but std.regex is brutally slow)Well yes, std.algorithm is practically all templates, and relatively small ones (except for bears like cartesianProduct, no thanks to yours truly :-/), so even though std.algorithm.* is pretty big in terms of LOC, you only pay for what you use. But std.regex has basically template-driven internals, and IIRC has static tables that are generated by templates and/or CTFE, so it can really slow the compiler down. The other big offender is std.uni, which imports some pretty large templated tables that adds a few seconds to compile times. All in all, though, the fact that we're complaining about extra seconds in compilation times still does show just how fast D compilation can be. In the old days, compiling large C++ codebases usually means 30 mins to 2 hours, and a few extra seconds won't even be noticed. I haven't checked C++ compile times recently, though -- things may have improved since I last seriously used C++. T -- IBM = I'll Buy Microsoft!
Nov 23 2018
On Friday, November 23, 2018 11:13:24 AM MST H. S. Teoh via Digitalmars-d- learn wrote:All in all, though, the fact that we're complaining about extra seconds in compilation times still does show just how fast D compilation can be. In the old days, compiling large C++ codebases usually means 30 mins to 2 hours, and a few extra seconds won't even be noticed. I haven't checked C++ compile times recently, though -- things may have improved since I last seriously used C++.When I was a student, I worked for a while at a company that had a large C++ code base that took over 3 hours to compile from scratch (incremental builds were an absolute must). I ended up working somewhere else for a while and then coming back again, and in the interim, they had begun redoing the program in Java. The build process then took about 10 minutes, and folks were complaining about it taking too long. After having been away for a while, my perspective was that it was a _huge_ improvement, but since they'd been working with it for a while, the 10 minutes was annoying. So, a lot of it comes down to perspective. D is often a _huge_ improvement when you first switch to it, but depending on what your code does, over time, it can go from under a second to a few seconds in compilation time, and for some folks that becomes maddening in spite of the fact that the overall build times are a huge improvement over what they would have had in another language - and usually, the features that slow down the build the most are ones that don't even exist in other languages (or if they do, are far less powerful). That being said, if we can reasonably improve the compiler and standard library such that D code in general builds faster with all of the CTFE and templates, we definitely should. - Jonathan M Davis
Nov 23 2018
On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:D is supposed to compile fast.You didnt read the fine print. It compiles simple code fast. Also compilation is separate step from linking and your program might spend half of "compilation" time in link phase.
Nov 24 2018
On Saturday, 24 November 2018 at 20:44:57 UTC, welkam wrote:On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:Wait wait wait wait wait. So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++? Two questions/topics/issues: ------------------------------------------------------- build program like DUB, MAKE, or CMAKE to do that? (Can make, cmake be used?) How do they recognize files are out-dated if DMD can't? Is that just an industry-standard specialization/separation-of-responsibilities to not have the compiler auto-detect up-to-date builds? I have the simplest project ever. Less than 10 files and my non-VStudio build-scripts have always been simple. A few lines or one long line running GCC/Clang/etc. I don't want to learn a make program's huge syntax just to compile a program if I can avoid it! (I've still got so many D and networking topics to learn on the back-burner!) I've heard "just use dub" but I've also heard that dub have flaws/gotchas that I can't remember when it comes to say, dynamic linking DLLs/SOs. So I've been hesitant to learn it. ------------------------------------------------------- std.regex is still, the Devil (TM), clocking in at almost FOUR SECONDS for a very simple set of code that simply matches lines for a poor-man's INI file parser (with a custom feature that allows tab indents to be nested sections). I was considering ripping it out and replacing it with JSON and this has REALLY motivated me to rip out the regex. Here's the file times: novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c molto.d Class 4 - Scaled Rotated hello hello -- it matches! real 0m0.377s user 0m0.344s sys 0m0.028s novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c helper.d real 0m0.118s user 0m0.096s sys 0m0.020s novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c editor.d real 0m0.626s user 0m0.536s sys 0m0.072s novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c common.d real 0m0.755s user 0m0.636s sys 0m0.092s novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c map.d real 0m1.045s user 0m0.904s sys 0m0.112s novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c object_t.d real 0m0.359s user 0m0.336s sys 0m0.024s novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c animation.d real 0m0.365s user 0m0.280s sys 0m0.068s novous saturn:~/Desktop/bitbucket/ss14$ time dmd -c ini.d real 0m3.672s <--- WOWZA user 0m3.292s sys 0m0.332s I have to tell you that, as an outsider (who is VERY interested in D), this is very frustrating. "Compile times are fast" != "build times" is a huge misconception that borders on being a clever lie or twisting of words. When people hear "compile times", they think "time to compile the whole project" not "time to compile a simple test case that doesn't use any typical D features--also, it's not linking." Second, as shown here, it's not fast even for compiling! Because the second you touch std.regex (which has NO WARNINGS in the documentation), you're greeted with another clever lie-by-omission: a 10x explosion of build time over some modules. Now let's stop for a moment. I'm not accusing anyone, and "lie" is a strong word with heavy guilt implications--like people are intentionally being very sneaky to deceive new-comers. I'm not saying any of that, so you can relax and put down the pitchfork. I'm not attacking you or your group personally. However, I can't think of any better word. So my point is, I keep running into either misconceptions that conveniently make D look good, and other gotchas with NO DOCUMENTATION that make the language much slower to work with than expected. And if I'm experiencing this, there are dozens (hundreds?) who hit the same roadblocks and gotchas and many people are much less forgiving/understanding than I am and simply just "give up" without ever telling you. So I'm trying to say this with the best of intentions. You can't have standard modules with no warning documentation that explode your RAM usage and compile times orders-of-a-magnitude more than other ones. You can have an "alpha" or "beta" or "Addon" or "external" module. But putting it in your standard framework implies that it works well with the other modules (::cough::std.variant and threads::cough::), and that it's not incredibly slower or more resource intensive. Having it in your standard library implies it meets a certain _STANDARD_. standard library that simply including it will swell your program to the point it can't compile? I'm not an omnipotent master programmer, but as a professional, I can't recall ever having this situation in another library or language. And it's very frustrating for someone who _wants_ to learn and use D. Thank you for your time, and I hope you had a great Thanksgiving.D is supposed to compile fast.You didnt read the fine print. It compiles simple code fast. Also compilation is separate step from linking and your program might spend half of "compilation" time in link phase.
Nov 25 2018
On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote:On Saturday, 24 November 2018 at 20:44:57 UTC, welkam wrote:"runs the files every time"? If that means "compiles the files every time", then no. D works exactly like C/C++ - you only need to compile-to-object-code source files in the project that have changed since the last time they were compiled.On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:Wait wait wait wait wait. So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++?D is supposed to compile fast.You didnt read the fine print. It compiles simple code fast. Also compilation is separate step from linking and your program might spend half of "compilation" time in link phase.
Nov 25 2018
On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote:So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++?Yes, C and C++ compilers behave the same way.a build program like DUB, MAKE, or CMAKE to do that? (Can make, cmake be used?) How do they recognize files are out-dated if DMD can't? Is that just an industry-standard specialization/separation-of-responsibilities to not have the compiler auto-detect up-to-date builds?cmake doesn't actually build anything. It generates make files or IDE project files. I don't know if DUB currently has an option to build only dirty files. Make does it by default. To do something like that requires looking for a source file's corresponding object file in the output directory and only compiling the source if the object file doesn't exist or if it has an older timestamp. But consider what happens when you change the command line options, say enable a version on a build that wasn't enabled earlier. With make, you have to run `make clean` first, otherwise only dirty files will get the new options. It doesn't track build options per file from run to run. What should the compiler do? Have a -clean command line switch? Maintain a database of command line options per file? That's the realm of build systems. The compiler just compiles.I've heard "just use dub" but I've also heard that dub have flaws/gotchas that I can't remember when it comes to say, dynamic linking DLLs/SOs. So I've been hesitant to learn it.DUB is easy. I've been using it for years and I do full compilation of every file on every invocation in a code->build->run cycle. Some aren't happy with it because it doesn't support some of the things they want to use it for, but it has plenty of satisfied users. I'm unaware of any gotchas about linking shared libraries.------------------------------------------------------- I have to tell you that, as an outsider (who is VERY interested in D), this is very frustrating. "Compile times are fast" != "build times" is a huge misconception that borders on being a clever lie or twisting of words. When people hear "compile times", they think "time to compile the whole project" not "time to compile a simple test case that doesn't use any typical D features--also, it's not linking." Second, as shown here, it's not fast even for compiling! Because the second you touch std.regex (which has NO WARNINGS in the documentation), you're greeted with another clever lie-by-omission: a 10x explosion of build time over some modules. Now let's stop for a moment. I'm not accusing anyone, and "lie" is a strong word with heavy guilt implications--like people are intentionally being very sneaky to deceive new-comers. I'm not saying any of that, so you can relax and put down the pitchfork. I'm not attacking you or your group personally. However, I can't think of any better word. So my point is, I keep running into either misconceptions that conveniently make D look good, and other gotchas with NO DOCUMENTATION that make the language much slower to work with than expected.There is no misleading or misconception or lying or misdirection here. DMD has fast compile times. Heavily templated code is going to slow it down, but if you compile the same sort of heavily templated code in C++, you'll get slow downs there as well. And in your case, you'll find that if you add many more files to your project and they aren't heavily templated, the increase in build time will be very small. If someone can dig into the compilers and optimize how templates are handled, they might be able to shave a bit of time off, but when you are using a code base that does a lot of work at compile time, then there's no avoiding increasing the length of that compile time. But that by no means is the same as saying it's not fast, because overall compile times in D are still fast.standard library that simply including it will swell your program to the point it can't compile? I'm not an omnipotent master programmer, but as a professional, I can't recall ever having this situation in another library or language.Have you reached the point in D where you can't compile?
Nov 25 2018
On Monday, 26 November 2018 at 03:09:03 UTC, Mike Parker wrote:I thought people had reached that point already: https://forum.dlang.org/post/mailman.3134.1517944133.9493.digitalmars-d puremagic.com I remember reading about a never ending for loop as well. Because of the way ctfe has to be handled "purely" without mutations, every change is a new allocation (but i could be remembering wrong). So just a large enough for loop because "uncompliable". And this is just time, the memory consumption is also quite large no? I think there are some caveats which are not mentioned when it comes to the fastness of the compiler. I remember last year's advent of code, I wanted to do everything at compile time, but at some point I thought, no, this small piece of code is taking way too long. Not worth it. And me mate's Go code was "consistently" fast.I mean, can you think of any module in the will swell your program to the point it can't compile? I'm not an omnipotent master programmer, but as a professional, I can't recall ever having this situation in another library or language.Have you reached the point in D where you can't compile?
Nov 26 2018
On Sunday, 25 November 2018 at 22:00:21 UTC, Chris Katko wrote:.So 1) I have to compile manually, then link. Except that also runs the files every time even if they're up-to-date. Is that normal behavior for C/C++?Well you dont have to use separate commands but yes compiling and linking are two steps and its normal behavior for all native languages. Each OS have their own linker and we dont control that.Two questions/topics/issues: ------------------------------------------------------- a build program like DUB, MAKE, or CMAKE to do that? (Can make, cmake be used?) How do they recognize files are out-dated if DMD can't? Is that just an industry-standard specialization/separation-of-responsibilities to not have the compiler auto-detect up-to-date builds?Yes its separation of responsibilities and there are many tools to automate that. Take a look at rdmd "rdmd recompiles files only on a needed basis, e.g. two invocations of rdmd in sequence without an intervening change to any relevant source file does not produce the executable again." https://dlang.org/rdmd.html If dub or rdmd doesnt satisfy your needs then you will need to learn other build system.I have to tell you that, as an outsider (who is VERY interested in D), this is very frustrating. "Compile times are fast" != "build times" is a huge misconception that borders on being a clever lie or twisting of words. When people hear "compile times", they think "time to compile the whole project" not "time to compile a simple test case that doesn't use any typical D features--also, it's not linking." Second, as shown here, it's not fast even for compiling! Because the second you touch std.regex (which has NO WARNINGS in the documentation), you're greeted with another clever lie-by-omission: a 10x explosion of build time over some modules.Yes D have some rough spots thats for sure. For compile times these include std.regex, std.format and heavy CTFE use. There is newCTFE engine that is faster but its not ready yet. That said D code compiles faster than C++ and Rust. To really put fast into perspective read this https://news.ycombinator.com/item?id=18442941So my point is, I keep running into either misconceptions that conveniently make D look good, and other gotchas with NO DOCUMENTATION that make the language much slower to work with than expected.People who advertise languages talk about positives and leave out negatives. One thing you need to know - D doesnt have huge sponsor and some places might be rough because of it. Currently core dev team focus more on stability and bug fixes than build speeds. I think you rather have compiler that works than compiler that crashes 1 sec faster. Its not all negatives with regex. Current regex implementation is one of the fastest in the world. Thats classic D trade of - you spend compile time for better runtime.standard library that simply including it will swell your program to the point it can't compile?Have you tried C++ boost?
Nov 26 2018
On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:Any time I see people mention the benefits of D, I see "compile times" "compile times" "compile times" over and over. I'm using very modest amounts of templates, for a fairly small sized program (very early work toward a game), and I'm hitting ~15 seconds compile time in LDC and ~7 seconds in DMD. And I'm not even compiling with optimizations! ldc2 -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -L-L. $ -gc -d-debug=3 -de -fdmd-trace-functions dmd -w -ofextra extra.d molto.d helper.d editor.d common.d map.d object_t.d animation.d ini.d -profile=gc -profile -g -debug -color -L-L. I keep putting stuff into new files, but it feels like it's compiling everything from scratch / not getting faster the way C++ does. And I'm not even bringing up the 800MB of RAM required because I dared to import std.regex. (On a laptop with 2 GB of RAM. RIP. If I dare to have tabs open, the compile time goes into the minutes thanks to swapping.)I've profiled your example, unsurprisingly allmost all of the compiletime is eaten by regex, which is executed at compile-time. Most of the time there is actually taken by the template-instantiation and the templates which are involved in building the IR and such. newCTFE helps out a little, but for this to be fast, std.regex would have to be rewritten with CTFE in mind. Maybe you can generate a finite automaton for your regex offline using some other engine like which supports D or C. That alone should cut a few seconds of your compile-times and prevent out-of-memory errors, I hope this helps. Cheers, Stefan
Nov 26 2018