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:
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.
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:
-------------------------------------------------------
#1 How to I only build files that are dirty? Do I actually need 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?
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.
#2 I ran individual file times. They're pretty shocking.
-------------------------------------------------------
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_.
I mean, can you think of any module in the Python/Javascript/C#
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.
