From: Óscar F. <of...@wa...> - 2013-06-11 10:12:25
|
For a project I'm working on the process takes about 4 times longer to start when compiled with MinGW's g++ than with VS. If I switch to using static libstdc++ and libgcc the process starts as fast as with VS. However, that change means larger executables and, worse, problems with exception propagation across dlls and (AFAIK) ownership conflicts with certain objects managed by libstdc++ and libgcc. Process start time is a problem here because the project (a compiler) contains a test suite that consists of thousands of test cases, each requiring a process execution. How could I improve process start time without the problems related to static runtime libraries? (The larger executable size I can live with, not the other problems) |
From: Earnie B. <ea...@us...> - 2013-06-11 17:48:37
|
On Tue, Jun 11, 2013 at 6:12 AM, Óscar Fuentes wrote: > For a project I'm working on the process takes about 4 times longer to > start when compiled with MinGW's g++ than with VS. If I switch to using > static libstdc++ and libgcc the process starts as fast as with VS. > However, that change means larger executables and, worse, problems with > exception propagation across dlls and (AFAIK) ownership conflicts with > certain objects managed by libstdc++ and libgcc. > > Process start time is a problem here because the project (a compiler) > contains a test suite that consists of thousands of test cases, each > requiring a process execution. > > How could I improve process start time without the problems related to > static runtime libraries? (The larger executable size I can live with, > not the other problems) The difference is likely due to the fact that the required DLL used by the VS version are already loaded in memory. To overcome this issue you would need to create a stub program whose only purpose is to ensure that the GCC DLL stay loaded in memory. You could have this stub program load on startup so that your compiler would not see the effect of loading the DLL into memory. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Óscar F. <of...@wa...> - 2013-06-11 18:50:40
|
Hello Earnie. Earnie Boyd <ea...@us...> writes: >> How could I improve process start time without the problems related to >> static runtime libraries? (The larger executable size I can live with, >> not the other problems) > > The difference is likely due to the fact that the required DLL used by > the VS version are already loaded in memory. To overcome this issue > you would need to create a stub program whose only purpose is to > ensure that the GCC DLL stay loaded in memory. You could have this > stub program load on startup so that your compiler would not see the > effect of loading the DLL into memory. On my test machine, the test suite runs 4 tests on parallel, so almost all of the time there is a running process when a new one is started. But just to be sure, I did as you suggested and no change was observed. |
From: Óscar F. <of...@wa...> - 2013-06-12 17:33:28
|
Óscar Fuentes <of...@wa...> writes: > Earnie Boyd <ea...@us...> > writes: > >>> How could I improve process start time without the problems related to >>> static runtime libraries? (The larger executable size I can live with, >>> not the other problems) >> >> The difference is likely due to the fact that the required DLL used by >> the VS version are already loaded in memory. To overcome this issue >> you would need to create a stub program whose only purpose is to >> ensure that the GCC DLL stay loaded in memory. You could have this >> stub program load on startup so that your compiler would not see the >> effect of loading the DLL into memory. > > On my test machine, the test suite runs 4 tests on parallel, so almost > all of the time there is a running process when a new one is started. > But just to be sure, I did as you suggested and no change was observed. Earnie, could this issue be the culprit of the slowness I'm experiencing? http://sourceforge.net/p/mingw/bugs/1747/ I reached there from http://stackoverflow.com/questions/15310996/clang-slow-startup-using-mingw which mentions that one workaround is to use static libraries (hence the problem happens when using dlls.) |
From: Earnie B. <ea...@us...> - 2013-06-13 12:37:16
|
On Wed, Jun 12, 2013 at 1:33 PM, Óscar Fuentes wrote: > Earnie, could this issue be the culprit of the slowness I'm > experiencing? > > http://sourceforge.net/p/mingw/bugs/1747/ > Yes, it is possible. The patch given will need to be reworked against the current revisions. I've marked the patch to be released with 4.1, currently still working on 4.0. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Óscar F. <of...@wa...> - 2013-06-14 01:23:25
|
Earnie Boyd <ea...@us...> writes: > Yes, it is possible. The patch given will need to be reworked against > the current revisions. I've marked the patch to be released with 4.1, > currently still working on 4.0. Thanks. |