On Thu, Aug 15, 2019 at 06:53:53PM +0000, Exil via Digitalmars-d wrote:
> On Thursday, 15 August 2019 at 15:00:43 UTC, Atila Neves wrote:
> > On Thursday, 15 August 2019 at 00:45:06 UTC, matheus wrote:
[...]
> > > I can't see a great difference between 1 sec vs 100 ms "while working".
> > 
> > I can. It makes me want to punch the wall.
> 
> The difference is noticable but really not to that point. What do you do when you have to wait 30 mins? I guess some people are just less trigger happy and patient than others.

Keep in mind, you're talking to a long-time D user who has gotten used to lightning-fast compile speeds.

In the old days, when I was still using C/C++ by choice, compilation breaks were an accepted norm. It's just the thing that you do after X minutes of coding, and it's known that it's a slow process.  You just take a coffee break, a washroom break, browse the internet, or whatever, and then resume working when the build is done.  It's just the way things were.  Working continuously was unimaginable, and you never missed it because you never experienced such a thing before.

Now that I'm used to D compilation speeds, I find anything longer than 3-5 seconds totally intolerable.  With a <1-2 second turnaround time, I find myself in a completely different mode of thought -- I can try out experimental bits of code and get almost instant feedback on the effect it has on the program.  Within a short 5-minute span I can have already tested out 20-25 different implementation ideas and zeroed in on the best one.  Your train of thought can actually proceed uninterrupted, and your coding process gets elevated to a new level of intense focus and productivity.  Whereas back in the day of C/C++ slow compiles, such a process would have taken hours, if not days, and development speed would be tortoise-slow.

Once you've tasted this level of coding focus and productivity, going back to the old way is simply unpalatable.  You find yourself losing your train of thought, distracted by other things during compilation and need to spend (i.e., waste) some time to refocus afterwards to get back in the groove.  Productivity is abysmal, relatively speaking.  Too much time wasted redirecting your attention from various distractions back to the problem at hand.  Like having to constantly switch your hand from the keyboard to the mouse instead of a keyboard-driven UI where your fingers are right there and ready to go, having a slow compile just pulls you back an order of magnitude in productivity. (I used to use a mouse-driven GUI for decades -- now I use a 99.99% keyboard-only interface with no distracting frills, and I can tell you productivity has skyrocketed to a whole 'nother level never before imaginable.)


[...]
> > No, it's not that. It's that it interrupts my train of thought. I can work faster if I get faster feedback.
> 
> Wouldn't compiler errors do the same.thing, if not worse? Not only do they interrupt your train of thought they require you to think about something else entirely. What do you do when you get a compiler error?

Compile errors that appear instantly means you're still focused and can immediately get on the task of identifying the problem code.  Compile errors that appear after X seconds means you spend an additional Y seconds refocusing your brain on the programming problem at hand, and *then* get on the task of identifying the problem code, thus slowing you down by (X+Y+Z) seconds rather than just spending the Z seconds finding the problem.


[...]
> > > Now imagine waiting ~40 seconds just to open any solution on Visual Studio (Mostly used for projects where I work), on a NOT so old machine, and like 4 ~ 10 seconds every time you run an app while debugging.
> > > 
> > > That's is the meaning of pain.

And that is why I don't bother with IDEs, or anything, really, that has needless eye-candy and frills I don't use. Give me vim over an SSH remote connection, and I can be 100% productive anywhere.  A GUI that requires umpteen GBs of RAM and 40s to start?  Not even on my radar.


> > I can take waiting 40s once a day. I can't take waiting >1s every time I build though.
> 
> Feel like you don't have to wait. You can continue to do other things while it is compiling. I suppose some people aren't as good at multi tasking.

It's not an issue of multitasking.  It's an issue of wasting time because you have to keep switching mental gears.  Context-switching is not free, even in the human brain. :-D  (I'd even say *especially* in the human brain -- CPU context switches are basically undetectable as far as human perception is concerned, but switching mental gears definitely takes a much more significant amount of time.)


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

On Thursday, 15 August 2019 at 18:53:53 UTC, Exil wrote:
> Don't know any compiler that's that fast, definitely not D and not even Jai.

You ever use D1?

I still have some of my old games written in it.

I went back to it briefly not long ago. I thought the compiler was broken because there was no visible delay at all - it was done faster than my prompt would reappear.

D used to be really fast. used to be :(

On Thursday, 15 August 2019 at 19:50:51 UTC, Adam D. Ruppe wrote:
> On Thursday, 15 August 2019 at 18:53:53 UTC, Exil wrote:
>> Don't know any compiler that's that fast, definitely not D and not even Jai.
>
> You ever use D1?
>
> I still have some of my old games written in it.
>
> I went back to it briefly not long ago. I thought the compiler was broken because there was no visible delay at all - it was done faster than my prompt would reappear.
>
> D used to be really fast. used to be :(

Could you please share what happened since D1 or the main cause?

Matheus.

On Thursday, 15 August 2019 at 19:30:44 UTC, H. S. Teoh wrote:
> On Thu, Aug 15, 2019 at 06:53:53PM +0000, Exil via Digitalmars-d wrote:
>> On Thursday, 15 August 2019 at 15:00:43 UTC, Atila Neves wrote:
>> > On Thursday, 15 August 2019 at 00:45:06 UTC, matheus wrote:
> [...]
>> > > I can't see a great difference between 1 sec vs 100 ms "while working".
>> > 
>> > I can. It makes me want to punch the wall.
>> 
>> The difference is noticable but really not to that point. What do you do when you have to wait 30 mins? I guess some people are just less trigger happy and patient than others.
>
> Keep in mind, you're talking to a long-time D user who has gotten used to lightning-fast compile speeds.
>
> In the old days, when I was still using C/C++ by choice, compilation breaks were an accepted norm. It's just the thing that you do after X minutes of coding, and it's known that it's a slow process.  You just take a coffee break, a washroom break, browse the internet, or whatever, and then resume working when the build is done.  It's just the way things were.
>  Working continuously was unimaginable, and you never missed it because you never experienced such a thing before.
>
> Now that I'm used to D compilation speeds, I find anything longer than 3-5 seconds totally intolerable.  With a <1-2 second turnaround time, I find myself in a completely different mode of thought -- I can try out experimental bits of code and get almost instant feedback on the effect it has on the program.  Within a short 5-minute span I can have already tested out 20-25 different implementation ideas and zeroed in on the best one.  Your train of thought can actually proceed uninterrupted, and your coding process gets elevated to a new level of intense focus and productivity.  Whereas back in the day of C/C++ slow compiles, such a process would have taken hours, if not days, and development speed would be tortoise-slow.
>
> Once you've tasted this level of coding focus and productivity, going back to the old way is simply unpalatable.  You find yourself losing your train of thought, distracted by other things during compilation and need to spend (i.e., waste) some time to refocus afterwards to get back in the groove.  Productivity is abysmal, relatively speaking.  Too much time wasted redirecting your attention from various distractions back to the problem at hand.  Like having to constantly switch your hand from the keyboard to the mouse instead of a keyboard-driven UI where your fingers are right there and ready to go, having a slow compile just pulls you back an order of magnitude in productivity. (I used to use a mouse-driven GUI for decades -- now I use a 99.99% keyboard-only interface with no distracting frills, and I can tell you productivity has skyrocketed to a whole 'nother level never before imaginable.)
>

See my experience with D is that it still takes over a minute to compile my relatively small program. A minute isn't really fast. Even worse if you use -O with DMD (I stopped it after 20 mins). D really isn't a fast language, or rather the only frontend is really really slow especially for CTFE.

> [...]
>> > No, it's not that. It's that it interrupts my train of thought. I can work faster if I get faster feedback.
>> 
>> Wouldn't compiler errors do the same.thing, if not worse? Not only do they interrupt your train of thought they require you to think about something else entirely. What do you do when you get a compiler error?
>
> Compile errors that appear instantly means you're still focused and can immediately get on the task of identifying the problem code.  Compile errors that appear after X seconds means you spend an additional Y seconds refocusing your brain on the programming problem at hand, and *then* get on the task of identifying the problem code, thus slowing you down by (X+Y+Z) seconds rather than just spending the Z seconds finding the problem.

Now you have to read and interpret something else entirely. Your not waiting 200 ms to continue your line of thought, your wasting minutes if not more if you continue to get compiler errors. Especially one of those template errors that are difficult to interpret. It's the same problem but x10 worse. Your not the person I was replying to, so sure maybe its something else to you, but the person I was replying to made it pretty clear what it was for them.

Just curious, how fast do you type? If it's about wasting time for you I imagine you must type pretty quickly then :P.

>
> [...]
>> > > Now imagine waiting ~40 seconds just to open any solution on Visual Studio (Mostly used for projects where I work), on a NOT so old machine, and like 4 ~ 10 seconds every time you run an app while debugging.
>> > > 
>> > > That's is the meaning of pain.
>
> And that is why I don't bother with IDEs, or anything, really, that has needless eye-candy and frills I don't use. Give me vim over an SSH remote connection, and I can be 100% productive anywhere.  A GUI that requires umpteen GBs of RAM and 40s to start?  Not even on my radar.

Haven't use an IDE in a long time either. The only one that's ever really been of note is Visual Studio, and their release cycles or so slow. They don't really add anything to the IDE anymore. It's mostly just the compiler they are updating. Compared to other Editors that release a new build every month. There's only really a handful of features that make IDEs useful for productivity, most editors have a few of those features, even less has most of them.

>
>> > I can take waiting 40s once a day. I can't take waiting >1s every time I build though.
>> 
>> Feel like you don't have to wait. You can continue to do other things while it is compiling. I suppose some people aren't as good at multi tasking.
>
> It's not an issue of multitasking.  It's an issue of wasting time because you have to keep switching mental gears.  Context-switching is not free, even in the human brain. :-D  (I'd even say *especially* in the human brain -- CPU context switches are basically undetectable as far as human perception is concerned, but switching mental gears definitely takes a much more significant amount of time.)
>
>
> T

You've just described multi tasking. If you have trouble keeping multiple things in your head at once and it takes you a long time to recall where you were in two unrelated tasks that you were doing relatively closely together. Then you aren't very good at multi-tasking.

On Thursday, 15 August 2019 at 19:30:44 UTC, H. S. Teoh wrote:
> [...]
>> > > Now imagine waiting ~40 seconds just to open any solution on Visual Studio (Mostly used for projects where I work), on a NOT so old machine, and like 4 ~ 10 seconds every time you run an app while debugging.
>> > > 
>> > > That's is the meaning of pain.
>
> And that is why I don't bother with IDEs, or anything, really, that has needless eye-candy and frills I don't use. Give me vim over an SSH remote connection, and I can be 100% productive anywhere.  A GUI that requires umpteen GBs of RAM and 40s to start?  Not even on my radar.
> ...

I don't like either. I just use where I work because it's pretty much a norm there. For my own projects I use plain text editor.

Well I still have a version of Visual C++ 6.0 (98?) installed on an old Windows Machine, which I use sometimes when I write C code because the great debugger and since it's a old software, it's blazing fast even on that old machine.

In fact it's literally faster than a blink, even with big projects like Game Engines.

Matheus.

On Thursday, 15 August 2019 at 19:50:51 UTC, Adam D. Ruppe wrote:
> On Thursday, 15 August 2019 at 18:53:53 UTC, Exil wrote:
>> Don't know any compiler that's that fast, definitely not D and not even Jai.
>
> You ever use D1?
>
> I still have some of my old games written in it.
>
> I went back to it briefly not long ago. I thought the compiler was broken because there was no visible delay at all - it was done faster than my prompt would reappear.
>
> D used to be really fast. used to be :(

It still is, if you're able to avoid templates. I get the impression that templates are very popular with D programmers.

On Thu, Aug 15, 2019 at 08:09:33PM +0000, Exil via Digitalmars-d wrote: [...]
> See my experience with D is that it still takes over a minute to compile my relatively small program.

I've seen that before.  The cause is usually one or more of:

(1) Using dub.  Dub is, sorry to say, dog-slow.  I do not bother with dub because of that (plus a variety of other reasons).  I use a saner build system that invokes dmd directly, and it's a lot faster than using dub.

(2) Using too many templates / CTFE.  CTFE is known to be dog-slow (Diet templates are a leading cause of dog-slow compilation in vibe.d projects, because they try to do too much at compile-time. I haven't gotten around to it yet, but in my own vibe.d project the goal is to move away from Diet templates and use a faster, home-brew HTML generation solution instead.)  NewCTFE is supposed to improve this, but at the rate things are going, I'm not holding my breath for it.

Templates are also known to be slow when you get into recursive templates or just careless, wanton use of compile-time arguments where runtime arguments do just fine.  If you reduce your use of templates, and use runtime code where it's not important to stuff everything into compile-time, your compile times will improve a lot.

(3) Using certain Phobos modules that are known to be very slow to compile, such as std.regex.  The underlying cause is essentially the same as (2), but I thought I'd point it out because sometimes it's not obvious that that's the problem when all you did was to import Phobos.


> A minute isn't really fast.

If my D project is taking a minute to compile, I'd seriously look into eliminating needless templates/CTFE and/or replacing dog-slow Phobos modules with custom code.


> Even worse if you use -O with DMD (I stopped it after 20 mins).

IMNSHO, using -O with DMD is a waste of time.  It increases compilation time, and has a higher probability of running into a compiler (usu. backend) bug, yet the resulting executable is still woefully suboptimal compared to, say, gdc or ldc.  Just not worth it.  If performance was important to me (and it is, in some of my projects), I'd just use ldc2 outright and forget about DMD.


> D really isn't a fast language, or rather the only frontend is really really slow especially for CTFE.

I understand the sentiment, but I think it's an unfair comparison.  If I were to implement in C++ the equivalent of the some CTFE functionality that's making my compilation slow, I'm almost certain the resulting C++ compile times will make dmd look like lightning speed by comparison. CTFE *is* known to be slow, no question about that, but I suspect it's still a lot faster than what it would have taken to accomplish the same thing in C++.


[...]
> > Compile errors that appear instantly means you're still focused and can immediately get on the task of identifying the problem code. Compile errors that appear after X seconds means you spend an additional Y seconds refocusing your brain on the programming problem at hand, and *then* get on the task of identifying the problem code, thus slowing you down by (X+Y+Z) seconds rather than just spending the Z seconds finding the problem.
> 
> Now you have to read and interpret something else entirely. Your not waiting 200 ms to continue your line of thought, your wasting minutes if not more if you continue to get compiler errors. Especially one of those template errors that are difficult to interpret. It's the same problem but x10 worse.

But you have to spend that time *anyway*, eventually if not right then, when you have to fix the bug in your code.  Why make the total time even longer by being forced to wait for long compilation times?


> Your not the person I was replying to, so sure
> maybe its something else to you, but the person I was replying to made
> it pretty clear what it was for them.
> 
> Just curious, how fast do you type? If it's about wasting time for you I imagine you must type pretty quickly then :P.
[...]

I type relatively fast -- not super-fast, mind you, but the point is that long compilation times are *on top* of my typing times.  If I'm already typing not super-fast, then I really don't want compilation times to make the total time even longer.


T

-- 
Creativity is not an excuse for sloppiness.

On Thursday, 15 August 2019 at 22:37:16 UTC, H. S. Teoh wrote:
> On Thu, Aug 15, 2019 at 08:09:33PM +0000, Exil via Digitalmars-d wrote: [...]
> (2) Using too many templates / CTFE.  CTFE is known to be dog-slow. NewCTFE is supposed to improve this, but at the rate things are going, I'm not holding my breath for it.
>

Now, if you cloud hold your breath for about a year ....

Regarding phobos even worse than regex is std.uni and std.format which imports uni.
And because of importing also std.conv and std.stdio.

By removing all mentions of std.stdio.writeln and std.conv.to in my own code, I was a able to reduce my compile-times from 30s to 2s and reduce the memory usage from 26G to .6G.

On Thu, Aug 15, 2019 at 10:48:35PM +0000, Stefan Koch via Digitalmars-d wrote:
> On Thursday, 15 August 2019 at 22:37:16 UTC, H. S. Teoh wrote:
> > On Thu, Aug 15, 2019 at 08:09:33PM +0000, Exil via Digitalmars-d wrote:
> > [...]
> > (2) Using too many templates / CTFE.  CTFE is known to be dog-slow.
> > NewCTFE is supposed to improve this, but at the rate things are
> > going, I'm not holding my breath for it.
> > 
> 
> Now, if you cloud hold your breath for about a year ....

Whoa, now *that's* good news I've been dying to hear! :-)


> Regarding phobos even worse than regex is std.uni and std.format which
> imports uni.
> And because of importing also std.conv and std.stdio.

Oh yeah, std.format is a bear.  Sadly, I can't live without it (too addicted to format-string based string output), but every second spent waiting for std.format to compile (and it does increase compilation by a significant number of seconds) is a second of anguish and teeth-gritting ("Why is std.format so dog-slow to compile?!?!").


> By removing all mentions of std.stdio.writeln and std.conv.to in my own code, I was a able to reduce my compile-times from 30s to 2s and reduce the memory usage from 26G to .6G.
[...]

I thought std.conv.to wasn't *that* bad?  Well, I guess it depends on what you use it for.  The implementation *does* involve a ridiculous number of template expansions.  I can't help wondering if we could refactor the ridiculous number of toImpl overloads into a single function with static-if blocks to dispatch to the various different cases.

(This would also improve the documentation, which last I checked still suffers from sig constraint abuse, AKA exposing implementation details in the sig constraint that are irrelevant to the user, where it really should be a static-if + static-assert inside the implementation.)


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous

On Thursday, 15 August 2019 at 18:53:53 UTC, Exil wrote:
> On Thursday, 15 August 2019 at 15:00:43 UTC, Atila Neves wrote:
>> On Thursday, 15 August 2019 at 00:45:06 UTC, matheus wrote:
>>> On Friday, 9 August 2019 at 13:17:02 UTC, Atila Neves wrote:
>>>> From experience, it makes me work much slower if I don't get results in less than 100ms. If I'm not mistaken, IBM did a study on this that I read once but never managed to find again about how much faster people worked on short feedback cycles.
>>>
>>> This is bit an exaggeration right?
>>
>> No, no exaggeration.
>
> Don't know any compiler that's that fast, definitely not D and not even Jai.

dmd compiles "hello world" in 50ms on my system. Then I tried it on a file with 1000 functions that add two integers. 50ms again. The problem, of course, is that any real D code I write is mostly templates and CTFE. Then there's the unittest/phobos issue with templates.

> The difference is noticable but really not to that point. What do you do when you have to wait 30 mins?

Be 1000 times less productive.

> I guess some people are just less trigger happy and patient than others.

I guess so.

> Wouldn't compiler errors do the same.thing, if not worse? Not only do they interrupt your train of thought they require you to think about something else entirely. What do you do when you get a compiler error?

Not sure. I think it's a combination of not getting them that often and getting them early in the editor before I've actually finished typing that means they don't bother me nearly as much.

> Feel like you don't have to wait. You can continue to do other things while it is compiling. I suppose some people aren't as good at multi tasking.

Nobody is good at multi tasking (there are studies). A lot of people are really good at believing they are, though. CPUs have nothing on the brain when it comes to context switching.