digitalmars.D.learn - Slow start up time of runtime
- Dennis (10/10) Mar 20 2018 Simply running a "hello world.exe" takes, on my pc:
- bauss (8/18) Mar 20 2018 It's not necessarily the runtime that's slow.
- Dennis (28/32) Mar 20 2018 This is not concerning for large applications indeed. But say, I
- David Nadlinger (4/6) Mar 20 2018 The best solution would be to profile the startup process and
- Adam D. Ruppe (13/14) Mar 20 2018 I suspect you are seeing the Windows antivirus hitting you. D
- HeiHon (9/14) Mar 20 2018 I also noticed slow startup times for freshly compiled D programs.
- Dennis (23/34) Mar 20 2018 You're totally right, disabling real-time protection makes a
- rumbu (9/43) Mar 20 2018 I cannot guarantee that this is the cause, but I observed that
- HeiHon (8/13) Mar 21 2018 In Windows Security Center Settings (where you can disable
- Dennis (2/6) Mar 21 2018 I've done this too now, thanks for the tip!
- Adam D. Ruppe (2/9) Mar 21 2018 Awesome tip!
Simply running a "hello world.exe" takes, on my pc: 1.12s When compiled with dmd 0.62s When compiled with ldc 0.05s When compiled with dmc (C program) or dmd/ldc as a -betterC program I suppose initializing the runtime takes a lot of time. When making a simple command line utility, half a second of delay is highly undesirable. Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program?
Mar 20 2018
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:Simply running a "hello world.exe" takes, on my pc: 1.12s When compiled with dmd 0.62s When compiled with ldc 0.05s When compiled with dmc (C program) or dmd/ldc as a -betterC program I suppose initializing the runtime takes a lot of time. When making a simple command line utility, half a second of delay is highly undesirable. Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program?It's not necessarily the runtime that's slow. Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application. Besides there could be a lot other factors. Without actual compiler versions, compiler flags and example code then it's pretty much impossible to tell what's slow. For me it's certainly not that slow with dmd.
Mar 20 2018
On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application.This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents? On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:Without actual compiler versions, compiler flags and example code then it's pretty much impossible to tell what's slow.``` import core.stdc.stdio: printf; int main() { return printf("hello world"); } ``` Compiling with `dmd helloworld_printf.d` or `dmd -release -O -inline helloworld_printf.d` doesn't make a difference here: `Measure-Command {./helloworld_printf}` reports ~1.1s in any case. I'm using 2.079 but I doubt this is a regression. betterC version: ``` import core.stdc.stdio: printf; extern(C) int main() { return printf("hello world"); } ``` `dmd helloworld_betterc.d -betterC` `ldc2 helloworld_betterc.d -betterC` I now notice that without the -betterC flag it's also 0.05s. So I suppose defining a `_d_run_main` instead of a `extern(C) main` is causing the slow startup time.
Mar 20 2018
On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote:On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:To give some more context, I've been using some of the digital mars utilities and I admire their speed. A `grep -r "goto" *.d` could find and scan 1.7 MB of d-source files in 190ms, way before my D hello-world was even able to enter main. As far I know, these are just C programs. I wonder if I could make such fast utilities in D, or whether (idiomatic) D is not the right tool for this and I should use (better)C instead.Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application.This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents?
Mar 20 2018
On Tuesday, 20 March 2018 at 10:46:11 UTC, Dennis wrote:On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote:Have you tried other applications that doesn't just print and see if that matters? Try to write to a file instead of the standard output and see if that makes any difference between each compilation unit. Also remember that you don't compile with dmd for runtime speed, but compilation speed. For runtime speed you want to use ldc, since it optimizes code way better.On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:To give some more context, I've been using some of the digital mars utilities and I admire their speed. A `grep -r "goto" *.d` could find and scan 1.7 MB of d-source files in 190ms, way before my D hello-world was even able to enter main. As far I know, these are just C programs. I wonder if I could make such fast utilities in D, or whether (idiomatic) D is not the right tool for this and I should use (better)C instead.Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application.This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents?
Mar 20 2018
bauss <jj_1337 live.dk> On Tuesday, 20 March 2018 at 12:07:12 UTC, bauss wrote:On Tuesday, 20 March 2018 at 10:46:11 UTC, Dennis wrote:To add on to this. Typically dmd is better during development, ldc is better during deployment and release.On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote:Have you tried other applications that doesn't just print and see if that matters? Try to write to a file instead of the standard output and see if that makes any difference between each compilation unit. Also remember that you don't compile with dmd for runtime speed, but compilation speed. For runtime speed you want to use ldc, since it optimizes code way better.On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote:To give some more context, I've been using some of the digital mars utilities and I admire their speed. A `grep -r "goto" *.d` could find and scan 1.7 MB of d-source files in 190ms, way before my D hello-world was even able to enter main. As far I know, these are just C programs. I wonder if I could make such fast utilities in D, or whether (idiomatic) D is not the right tool for this and I should use (better)C instead.Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application.This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents?
Mar 20 2018
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program?The best solution would be to profile the startup process and file a bug accordingly. ;) — David
Mar 20 2018
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:I suppose initializing the runtime takes a lot of time.I suspect you are seeing the Windows antivirus hitting you. D runtime starts up in a tiny fraction of a second, you shouldn't be noticing it. Go into the Windows security center and uncheck the real time virus check protection. I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too) disappear and everything will seem a LOT faster. I don't know why the antivirus picks on D so much, but on my box it does and it sounds like it is on yours too. BTW that real time check box likes to keep turning itself on... so the slowness will keep coming back.
Mar 20 2018
On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:Go into the Windows security center and uncheck the real time virus check protection. I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too) disappear and everything will seem a LOT faster.I also noticed slow startup times for freshly compiled D programs. And yes, I can verify that it's the Windows Defender's realtime scan. I switched it off (Windows 10) and dmd itself and the compiled D program started just as fast as they should. It gets better (with realtime scan enabled) when you compile your programs with dmd -O -release -m64 app.d
Mar 20 2018
On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: I suspect you are seeing the Windows antivirus hitting you. D runtime starts up in a tiny fraction of a second, you shouldn't be noticing it.You're totally right, disabling real-time protection makes a massive difference. I always found a second exceptionally long for a runtime to initialize, but I couldn't think of any other differences between a simple dmd-compiled program and a simple dmc-compiled program. On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too)Definitely. I've tested how long tools take to simply print their help text: for the first time with virus scan, second time with virus scan and without any real-time protection. D tools seem to get the longest delay. First Second No protection (miliseconds) dmc 84 52 16 dmd 2400 1200 24 dub 2300 1100 25 ldc 4500 180 30 gcc 240 100 18 On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:I don't know why the antivirus picks on D so much, but on my box it does and it sounds like it is on yours too. BTW that real time check box likes to keep turning itself on... so the slowness will keep coming back.Typical Windows... It keeps turning on the Windows update service too. This now leaves the question what's the best way to mitigate this, because I would gladly get rid of the second of delay any time I invoke dmd, ldc or dub as well as my own applications.
Mar 20 2018
On Tuesday, 20 March 2018 at 16:56:59 UTC, Dennis wrote:On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:I cannot guarantee that this is the cause, but I observed that Bitdefender is very picky with Intel OMF format. I made a lot of complaints about this (it was impossible to debug a intel omf compiled exe with Bitdefender installed and the advice received from Bitdefender was to compile my executables in mscoff format. That's how my problem disappeared. Windows Defender incorporated last year Bitdefender scanning technology, maybe this is an explanation.On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: I suspect you are seeing the Windows antivirus hitting you. D runtime starts up in a tiny fraction of a second, you shouldn't be noticing it.You're totally right, disabling real-time protection makes a massive difference. I always found a second exceptionally long for a runtime to initialize, but I couldn't think of any other differences between a simple dmd-compiled program and a simple dmc-compiled program. On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too)Definitely. I've tested how long tools take to simply print their help text: for the first time with virus scan, second time with virus scan and without any real-time protection. D tools seem to get the longest delay. First Second No protection (miliseconds) dmc 84 52 16 dmd 2400 1200 24 dub 2300 1100 25 ldc 4500 180 30 gcc 240 100 18 On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:I don't know why the antivirus picks on D so much, but on my box it does and it sounds like it is on yours too. BTW that real time check box likes to keep turning itself on... so the slowness will keep coming back.Typical Windows... It keeps turning on the Windows update service too. This now leaves the question what's the best way to mitigate this, because I would gladly get rid of the second of delay any time I invoke dmd, ldc or dub as well as my own applications.
Mar 20 2018
On Tuesday, 20 March 2018 at 16:56:59 UTC, Dennis wrote:On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote:In Windows Security Center Settings (where you can disable realtime scan) there is also an entry "Exclusions" (in german windows "Ausschlüsse"). I added exclusions for the folder, where I installed dmd and ldc and I added an exclusion for the folder, where I compile my D programs. Now startup of dmd and freshly compiled programs is fast again.On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote:This now leaves the question what's the best way to mitigate this, because I would gladly get rid of the second of delay any time I invoke dmd, ldc or dub as well as my own applications.
Mar 21 2018
On Wednesday, 21 March 2018 at 13:26:48 UTC, HeiHon wrote:I added exclusions for the folder, where I installed dmd and ldc and I added an exclusion for the folder, where I compile my D programs. Now startup of dmd and freshly compiled programs is fast again.I've done this too now, thanks for the tip!
Mar 21 2018
On Wednesday, 21 March 2018 at 13:26:48 UTC, HeiHon wrote:In Windows Security Center Settings (where you can disable realtime scan) there is also an entry "Exclusions" (in german windows "Ausschlüsse"). I added exclusions for the folder, where I installed dmd and ldc and I added an exclusion for the folder, where I compile my D programs. Now startup of dmd and freshly compiled programs is fast again.Awesome tip!
Mar 21 2018