Re: Performance regression from 2.8.12 to 2.9.x with MinGW32 builds?

[Vadim Zeitlin]

On Thu, 2 Aug 2012 07:29:10 -0700 (PDT) Si wrote:

S> I'm seeing a very significant difference in startup time and memory
S> footprint for the Minimal sample app, when comparing 2.8.12 & 2.9.4 builds
S> on Windows with MinGW32.
...
S> This is a follow on question from a conversation at:
S> http://forums.wxwidgets.org/viewtopic.php?f=19&t=35542

You mention that you use 4.6 in this link...

S> WX : 2.8.12 & 2.9.4 (& latest nightlies, for comparison)
S> OS : Windows 7 (starter 32-bit and ultimate 64-bit), also verified on Vista 32-bit
S> COMPILER: mingw32-g++.exe (GCC) 4.7.0

... and 4.7.0 here, so I'm not sure which one is it. But for both of them
auto importing is used by default because using explicit
__attribute__((dllexport)) results in huge DLL size increase with g++ 4.6+,
see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 so we don't use it
any more. If your version of g++ can build 2.8 DLLs without problems,
perhaps this was somehow fixed in it, try removing "!wxCHECK_GCC_VERSION()"
test in wx/defs.h and rebuilding. Does it help?

S> OPTIONS : SHARED=1 BUILD=release (in setup.h for 2.9.4, #define
S> wxDEBUG_LEVEL 0)

To confirm that the problem is DLL-specific, try rebuilding with SHARED=0.
You shouldn't see any notable difference between 2.8 and 2.9 then. Do you?

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Si]

Hi Vadim,

I disabled the check in dlimpexp.h, and after a longer build simply got larger DLLs. No discernible Minimal.exe start time improvement.

There's some improvement for the static build Minimal.exe, but it's still sluggish compared to 2.8.12 and VC builds, and has the larger memory footprint:

16:17:49.0190675 minimal.exe 7876 Process Start SUCCESS

16:17:50.9616599 minimal.exe 7876 RegCloseKey HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes SUCCESS 0.0000032

I'm using mingw32-g++ 4.7.0 on my main dev machine (running these tests on Win 7 ultimate 64-bit), and it was the Atom based Win 7 starter 32-bit that has 4.6.2 installed (the bundled components haven't been updated to the latest versions online). Both setups have shown the issue however.

Thanks,

Si

[Vadim Zeitlin]

On Fri, 3 Aug 2012 07:42:23 -0700 (PDT) Si wrote:

S> I disabled the check in dlimpexp.h, and after a longer build simply got
S> larger DLLs. No discernible Minimal.exe start time improvement.

Sorry, I don't have any other ideas, this would need to be profiled to
gather more data. Do you have any working profiler? I'd be really
interested in seeing the results and, if possible, comparison with 2.8.

Thanks,

[Bob Paddock]

> I'm using mingw32-g++ 4.7.0

You can get a 4.7.1 version here, to see if that would make any
difference (I doubt it):

http://nuwen.net/mingw.html

Building a non-shared version of the minimal sample worked fine in
both debug (66 Meg) and release (8 meg).

[Si]

Profiling information is available here:

http://www.mintsource.org/Profiling.zip (12K)

I installed "Very Sleepy" to obtain it, and include the following files:

-rw-r--r--    1 Si       Administ     1213 Aug  3 17:45 gcc-2.8.12.csv

-rw-r--r--    1 Si       Administ     1167 Aug  3 17:45 gcc-2.8.12.sleepy

-rw-r--r--    1 Si       Administ    17788 Aug  3 17:44 gcc-2.9.4.csv

-rw-r--r--    1 Si       Administ     6246 Aug  3 17:43 gcc-2.9.4.sleepy

There is a lot more going on with the 2.9.4 build.

[Si]

It certainly starts faster for me with a static build, but there's a definite delay and increased memory footprint compared to GCC/2.8.12 & VC/ANY.

I might give the 4.7.1 version a go, thanks.

[Si]

Same result with the http://nuwen.net/mingw.html tool chain.

[Si]

For completeness, I have added the vc-2.9.4 and gcc-2.9.4 static profiling results to the zip. The static build shows the same kind of charactestics displayed by the gcc-2.9.4 DLL version. I believe all of these executables will have been launched at least once, prior to profiling.

http://www.mintsource.org/Profiling.zip (19K) 

-rw-r--r--    1 Si       Administ     1213 Aug  3 17:45 gcc-2.8.12.csv

-rw-r--r--    1 Si       Administ     1167 Aug  3 17:45 gcc-2.8.12.sleepy

-rw-r--r--    1 Si       Administ     7860 Aug  4 09:25 gcc-2.9.4-static.csv

-rw-r--r--    1 Si       Administ     3103 Aug  4 09:24 gcc-2.9.4-static.sleepy

-rw-r--r--    1 Si       Administ    17788 Aug  3 17:44 gcc-2.9.4.csv

-rw-r--r--    1 Si       Administ     6246 Aug  3 17:43 gcc-2.9.4.sleepy

-rw-r--r--    1 Si       Administ     1898 Aug  4 09:23 vc-2.9.4.csv

-rw-r--r--    1 Si       Administ     1323 Aug  4 09:23 vc-2.9.4.sleepy

[Vadim Zeitlin]

On Sat, 4 Aug 2012 00:24:11 -0700 (PDT) Si wrote:

S> For completeness, I have added the vc-2.9.4 and gcc-2.9.4 static profiling
S> results to the zip. The static build shows the same kind of charactestics
S> displayed by the gcc-2.9.4 DLL version. I believe all of these executables
S> will have been launched at least once, prior to profiling.
S>
S> http://www.mintsource.org/Profiling.zip (19K)

Thanks for the results but I'm not sure how to interpret them: what are
the meanings of the columns in the CSV file?

Also, what exactly is being profiled here? If the problem is really in the
startup code, my first idea would be to just return false from the
overridden wxApp::OnInit(), is this what you did?

[Si]

On Sunday, August 5, 2012 12:52:26 PM UTC+2, Vadim Zeitlin wrote:

 Thanks for the results but I'm not sure how to interpret them: what are
the meanings of the columns in the CSV file?

 Also, what exactly is being profiled here? If the problem is really in the
startup code, my first idea would be to just return false from the
overridden wxApp::OnInit(), is this what you did?

 Thanks,
VZ

 

The headings are function name, exclusive time, inclusive time, % exclusive, % inclusive, module, source file & source line.

It's the Minimal sample app that's being profiled in each case, free of any changes, and corresponding to the WxWidgets source bundle it came with.

[Vadim Zeitlin]

On Sun, 5 Aug 2012 04:07:33 -0700 (PDT) Si wrote:

S> The headings are function name, exclusive time, inclusive time, %
S> exclusive, % inclusive, module, source file & source line.

OK, thanks.

S> It's the Minimal sample app that's being profiled in each case, free of any
S> changes, and corresponding to the WxWidgets source bundle it came with.

But if you actually run it -- i.e. let the window appear on the screen and
then close it -- then the time spent actually running it should totally
dominate the total. Also, the results would be very inconsistent because
you wouldn't be able to terminate it at exactly the same time. So how
exactly do you do it?

IMHO, once again, the best would be to put "return false" in OnInit() to
profile just the startup code itself. If the problem is not there, then you
could also profile the new frame creation.

Regards,

[Si]

On Sunday, August 5, 2012 1:30:58 PM UTC+2, Vadim Zeitlin wrote:

 IMHO, once again, the best would be to put "return false" in OnInit() to
profile just the startup code itself. If the problem is not there, then you
could also profile the new frame creation.

OK, I now understand this in the profiling context. Good idea, I'll try it out and get back to you.

Thanks Vadim.

[Si]

On Sunday, August 5, 2012 1:30:58 PM UTC+2, Vadim Zeitlin wrote:

 IMHO, once again, the best would be to put "return false" in OnInit() to
profile just the startup code itself. If the problem is not there, then you
could also profile the new frame creation.

I've updated the zip at http://www.mintsource.org/Profiling.zip (22K).

It now includes gcc-2.8.12-oninit-false & gcc-2.9.4-oninit-false profile reports, however, 2.8.12 didn't actually report anything in Very Sleepy. Not an error, just no information gathered.

Something I noticed when rebuilding 2.8.12 was that it did take longer to create the libraries, consistent with the issue you mentioned before. However, the library sizes are not too bad (compiled with GCC 4.6.2):

-rwxr-xr-x    1 Si       Administ  4639199 Aug  5 15:02 /c/wxWidgets-2.8.12/lib/gcc_dll/wxbase28_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ   318647 Aug  5 15:02 /c/wxWidgets-2.8.12/lib/gcc_dll/wxbase28_net_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ   255598 Aug  5 15:02 /c/wxWidgets-2.8.12/lib/gcc_dll/wxbase28_xml_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ  1546597 Aug  5 15:03 /c/wxWidgets-2.8.12/lib/gcc_dll/wxmsw28_adv_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ   742645 Aug  5 15:03 /c/wxWidgets-2.8.12/lib/gcc_dll/wxmsw28_aui_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ 10849870 Aug  5 15:03 /c/wxWidgets-2.8.12/lib/gcc_dll/wxmsw28_core_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ  1082693 Aug  5 15:03 /c/wxWidgets-2.8.12/lib/gcc_dll/wxmsw28_html_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ   317263 Aug  5 15:03 /c/wxWidgets-2.8.12/lib/gcc_dll/wxmsw28_media_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ  1692723 Aug  5 15:03 /c/wxWidgets-2.8.12/lib/gcc_dll/wxmsw28_richtext_gcc_custom.dll

-rwxr-xr-x    1 Si       Administ   814630 Aug  5 15:03 /c/wxWidgets-2.8.12/lib/gcc_dll/wxmsw28_xrc_gcc_custom.dll

Timing wise, recording with "time" and returning false before base class OnInit, representative timings are:

2.8.12:

real    0m0.069s

user    0m0.015s

sys     0m0.015s

2.9.4:

real    0m0.723s

user    0m0.031s

sys     0m0.015s

There was no significant time difference when additionally initialising the base class and showing the frame.

[Vadim Zeitlin]

On Sun, 5 Aug 2012 06:20:17 -0700 (PDT) Si wrote:

S> I've updated the zip at http://www.mintsource.org/Profiling.zip (22K).

You really should start versioning or timestamping these files...

S> Timing wise, recording with "time" and returning false before base class
S> OnInit, representative timings are:
S>
S> 2.8.12:
S>
S> real 0m0.069s
S> user 0m0.015s
S> sys 0m0.015s
S>
S> 2.9.4:
S>
S> real 0m0.723s
S> user 0m0.031s
S> sys 0m0.015s
S>
S> There was no significant time difference when additionally initialising the
S> base class and showing the frame.

If the profiler is correct (and seeing that it didn't generate anything at
all for 2.8 I'm not totally sure about it), it's clear that almost the
entire time of running is spent on memory allocation (VirtualProtect(),
VirtualQuery()) inside inflate_table(). Now I have absolutely no idea why
is inflate_table() -- which is a libz function -- being called at all. So
could you please try to check (1) whether it's really called or if it's
just the profiler misbehaving and (2) where is it called from.

[Si]

On Sunday, August 5, 2012 5:35:14 PM UTC+2, Vadim Zeitlin wrote:

 If the profiler is correct (and seeing that it didn't generate anything at
all for 2.8 I'm not totally sure about it), it's clear that almost the
entire time of running is spent on memory allocation (VirtualProtect(),
VirtualQuery()) inside inflate_table(). Now I have absolutely no idea why
is inflate_table() -- which is a libz function -- being called at all. So
could you please try to check (1) whether it's really called or if it's
just the profiler misbehaving and (2) where is it called from.

 Regards,
VZ

Is there another freely available profiler I could use, that you have too?

inflate_table is called in three call stacks. In common for each case:

RtlAllocateHeap ntdll

LdrInitializeThunk ntdll

RtlSetUnhandledExceptionFilter ntdll

RtlGetNtVersionNumbers ntdll

LdrResSearchResource ntdll

RtlQueryEnvironmentVariable ntdll

[621010EE] wxmsw294u_core_gcc_custom

inflate_table wxmsw294u_core_gcc_custom

inflate_table wxmsw294u_core_gcc_custom (again)

Then for one stack, it goes no further.

For another call stack:

VirtualQuery KERNELBASE

ZwQueryVirtualMemory ntdll (Accounting for 0.18s)

And for the last call stack:

VirtualProtect KERNELBASE

NtProtextVirtualMemory ntdll (Accounting for 0.45s)

Dumping the function stats as CSV, re-rooted at [621010EE] wxmsw294u_core_gcc_custom:

NtProtectVirtualMemory,0.448534,0.448534,70.565821,70.565821,ntdll,[unknown],0

ZwQueryVirtualMemory,0.178089,0.178089,28.017935,28.017935,ntdll,[unknown],0

inflate_table,0.009002,0.635625,1.416244,100.000000,wxmsw294u_core_gcc_custom,[unknown],0

VirtualProtect,0.000000,0.448534,0.000000,70.565821,KERNELBASE,[unknown],0

VirtualQuery,0.000000,0.178089,0.000000,28.017935,KERNELBASE,[unknown],0

[621010EE],0.000000,0.635625,0.000000,100.000000,wxmsw294u_core_gcc_custom,,0

[Vadim Zeitlin]

On Sun, 5 Aug 2012 09:22:15 -0700 (PDT) Si wrote:

S> Is there another freely available profiler I could use, that you have too?

Unfortunately no. I use Intel XE Studio but it's not free and even if it
were, I don't think it works with MinGW as it probably doesn't understand
its debugging info format. The same applies to Visual Studio, which has a
pretty nice built-in profiler, and beta version of which can be downloaded
free of charge, but which only works with PDB too.

To learn where is the function being called from you don't need a profiler
however, a debugger (i.e. gdb) would do. Do you have a working gdb? If so,
is a breakpoint on this function getting hit? What does "bt" show then?

My suspicion is that the profiler output is just plain wrong... Now that i
think about it, what about gprof? Doesn't it exist for MinGW? It's
certainly available in Cygwin.

[Si]

I think you're right about the profiler. I can't hit the breakpoint in gdb, though it will hit VirtualProtect for example, or OnInit:

Breakpoint 1, 0x00402f64 in MyApp::OnInit() ()

(gdb) backtrace

#0  0x00402f64 in MyApp::OnInit() ()

#1  0x648b7e45 in wxEntryReal(int&, wchar_t**) ()

   from c:\wxWidgets-2.9.4\lib\gcc_dll\wxbase294u_gcc_custom.dll

#2  0x62108b69 in _fu3173___ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE () from c:\wxWidgets-2.9.4\lib\gcc_dll\wxmsw294u_core_gcc_custom.dll

#3  0x0040147f in WinMain@16 ()

#4  0x004041a6 in main (argc=-1869573949, argv=0xfffe9090,

    __p__environ=0xffff) at ../mingw/main.c:73

I'll have to noodle around more with gprof.... OK, I've got that working. Any idea how best to profile this, settings wise?

I currently only see:

Each sample counts as 0.01 seconds.

 no time accumulated

  %   cumulative   self              self     total

 time   seconds   seconds    calls  Ts/call  Ts/call  name

  0.00      0.00     0.00        1     0.00     0.00  WinMain@16

...blah...

granularity: each sample hit covers 4 byte(s) no time propagated

index % time    self  children    called     name

                0.00    0.00       1/1           main [623]

[2]      0.0    0.00    0.00       1         WinMain@16 [2]

...blah...

Index by function name

   [2] WinMain@16

[Vadim Zeitlin]

On Sun, 5 Aug 2012 10:44:11 -0700 (PDT) Si wrote:

S> I think you're right about the profiler. I can't hit the breakpoint in gdb,
S> though it will hit VirtualProtect for example, or OnInit:

You could do "statistical debugging" and try to break on VirtualAlloc() a
few times to see where is it called from so many times but it's a pretty
desperate method of profiling...

S> I'll have to noodle around more with gprof.... OK, I've got that working.

It doesn't look like it really worked. Did you rebuild everything with -pg?

[Si]

That was getting gprof to work basically, as I was seeing some build errors on first attempt. I was wondering if there were any special settings needed for the build or for gprof.

After a debug build of wxWdigets where additionally CPPFLAGS ?= -pg & LDFLAGS ?= -pg, I get the following:

Flat profile:

  %   cumulative   self              self     total

 time   seconds   seconds    calls  Ts/call  Ts/call  name

  0.00      0.00     0.00        1     0.00     0.00  WinMain@16

  0.00      0.00     0.00        1     0.00     0.00  MyApp::OnInit()

  0.00      0.00     0.00        1     0.00     0.00  MyApp::MyApp()

  0.00      0.00     0.00        1     0.00     0.00  MyApp::~MyApp()

granularity:

index % time    self  children    called     name

                0.00    0.00       1/1           main [670]

[2]      0.0    0.00    0.00       1         WinMain@16 [2]

-----------------------------------------------

                0.00    0.00       1/1           wxAppConsoleBase::CallOnInit()

[158]

[3]      0.0    0.00    0.00       1         MyApp::OnInit() [3]

-----------------------------------------------

                0.00    0.00       1/1           wxCreateApp() [23]

[4]      0.0    0.00    0.00       1         MyApp::MyApp() [4]

-----------------------------------------------

                0.00    0.00       1/1           MyApp::~MyApp() [275]

[5]      0.0    0.00    0.00       1         MyApp::~MyApp() [5]

-----------------------------------------------

Index by function name

   [2] WinMain@16              [4] MyApp::MyApp()

   [3] MyApp::OnInit()         [5] MyApp::~MyApp()

[Si]

I wasn't expecting this:

[Si@CAEMLYN minimal]$ time gcc_mswudll/minimal.exe

real    0m0.745s

user    0m0.062s

sys     0m0.000s

[Si@CAEMLYN minimal]$ time gcc_mswuddll/minimal.exe

real    0m0.159s

user    0m0.031s

sys     0m0.031s

 

[Si]

The time difference between debug and release builds is even more stark on the Atom based laptop. It starts up much more like the 2.8.12 build:

Si /c/wxWidgets-2.9.4/samples/minimal$ time gcc_mswudll/minimal.exe

real    0m2.137s

user    0m0.015s

sys     0m0.062s

Si /c/wxWidgets-2.9.4/samples/minimal$ time gcc_mswuddll/minimal.exe

real    0m0.328s

user    0m0.031s

sys     0m0.031s

[Vadim Zeitlin]

On Mon, 6 Aug 2012 01:03:31 -0700 (PDT) Si wrote:

S> After a debug build of wxWdigets where additionally CPPFLAGS ?= -pg
S> & LDFLAGS ?= -pg, I get the following:
S>
S> Flat profile:
S>
S> % cumulative self self total
S> time seconds seconds calls Ts/call Ts/call name
S> 0.00 0.00 0.00 1 0.00 0.00 WinMain@16
S> 0.00 0.00 0.00 1 0.00 0.00 MyApp::OnInit()
S> 0.00 0.00 0.00 1 0.00 0.00 MyApp::MyApp()
S> 0.00 0.00 0.00 1 0.00 0.00 MyApp::~MyApp()

It looks it's just not granular enough :-(

S> I wasn't expecting this:
S>
S> [Si@CAEMLYN minimal]$ time gcc_mswudll/minimal.exe
S>
S> real 0m0.745s
S> user 0m0.062s
S> sys 0m0.000s
S> [Si@CAEMLYN minimal]$ time gcc_mswuddll/minimal.exe
S>
S> real 0m0.159s
S> user 0m0.031s
S> sys 0m0.031s
...
S> The time difference between debug and release builds is even more stark on
S> the Atom based laptop. It starts up much more like the 2.8.12 build:
S>
S> Si /c/wxWidgets-2.9.4/samples/minimal$ time gcc_mswudll/minimal.exe
S>
S> real 0m2.137s
S> user 0m0.015s
S> sys 0m0.062s
S>
S> Si /c/wxWidgets-2.9.4/samples/minimal$ time gcc_mswuddll/minimal.exe
S>
S> real 0m0.328s
S> user 0m0.031s
S> sys 0m0.031s

So you say that the *release* build is ~10 times *slower* than the debug
one? I definitely wouldn't expect this neither... For Atom I could imagine
wx code using some emulated (and hence very slow) instructions because of
some wrong compilation options but this definitely can't be the case for
the normal desktop x86 case above. I frankly have no idea what could
explain this. What are the differences between two builds exactly? Do you
build using configure or "make -f makefile.gcc"?

Regards,

[Si]

Release minimal.exe also has a memory footprint of 10,848K compared to 7,476K for the debug version.

I'm building using "make -f makefile.gcc", but I'll try the configure route, and see what happens.

[Si]

On Monday, August 6, 2012 12:53:18 PM UTC+2, Vadim Zeitlin wrote:

 So you say that the *release* build is ~10 times *slower* than the debug
one? I definitely wouldn't expect this neither... For Atom I could imagine
wx code using some emulated (and hence very slow) instructions because of
some wrong compilation options but this definitely can't be the case for
the normal desktop x86 case above. I frankly have no idea what could
explain this. What are the differences between two builds exactly? Do you
build using configure or "make -f makefile.gcc"?

 Regards,
VZ

The configure route bails for me once configure hits src/expat, and attempts to re-configure. It wants make instead of mingw32-make, but copying the binary crashes with "Interrupt/Exception caught (code = 0xc0000005, addr = 0x760d43f9)".

I guess I'm stuck with the supplied makefile.gcc for now.

[ardi]

On Thursday, August 2, 2012 4:29:10 PM UTC+2, Si wrote:

Hi all,

I'm seeing a very significant difference in startup time and memory footprint for the Minimal sample app, when comparing 2.8.12 & 2.9.4 builds on Windows with MinGW32. Visual C++ builds consistently perform excellently.

Thanks for digging into this. I don't know if I'm hitting this issue, but I'm certainly a candidate because I build with mingw, although with a different setting: I cross-build from OSX to Win32 using mingw64 (I'm at gcc 4.6.3, though). If you find that this is a widespread issue for all people building 2.9.x for MSW through mingw, please tell!

ardi

[Si]

On Monday, August 6, 2012 12:53:18 PM UTC+2, Vadim Zeitlin wrote:

 So you say that the *release* build is ~10 times *slower* than the debug
one? I definitely wouldn't expect this neither... For Atom I could imagine
wx code using some emulated (and hence very slow) instructions because of
some wrong compilation options but this definitely can't be the case for
the normal desktop x86 case above. I frankly have no idea what could
explain this. What are the differences between two builds exactly? Do you
build using configure or "make -f makefile.gcc"?

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

From a completely fresh wxWidgets-2.9.4 and as-bundled MinGW using the current version get system:

Set SHARED ?= 1 in build\msw\config.gcc.

mingw32-make -j 8 -f makefile.gcc & then likewise for samples\minimal.

Memory footprint for this debug build is 3,768K. Hacking the OnInit to return false gives:

real    0m0.256s

user    0m0.015s

sys     0m0.015s

Then, set BUILD ?= release in build\msw\config.gcc.

Making this gives a memory footprint of 6,564K when window allowed to show. Timings for hacked OnInit:

real    0m2.084s

user    0m0.031s

sys     0m0.016s

That's even worse than the previous time, but then, no "performance boosters" like -pg could slipped into the build! :)

[Vadim Zeitlin]

On Mon, 6 Aug 2012 05:34:41 -0700 (PDT) Si wrote:

S> Memory footprint for this debug build is 3,768K.

How do you measure the memory footprint BTW?

S> Hacking the OnInit to return false gives:
S>
S> real 0m0.256s
S> user 0m0.015s
S> sys 0m0.015s
S>
S> Then, set BUILD ?= release in build\msw\config.gcc.
S>
S> Making this gives a memory footprint of 6,564K when window allowed to show.
S> Timings for hacked OnInit:
S>
S> real 0m2.084s
S> user 0m0.031s
S> sys 0m0.016s

I really can't explain this. Can anybody else reproduce these results?

I definitely don't see this here for the binaries cross-compiled from
Linux using MinGW 4.2.1. Even though the executable is ran from a network
(Samba) disk, it starts up in ~0.01s.

[Si]

Those cross-compile results sound great. I'll have to give that a go.

A couple of other WxWidgets users on the http://forums.wxwidgets.org/viewtopic.php?f=19&t=35542 forum thread have also seen the increased startup time and memory footprint issues, but I'd love to hear experiences either way.

I like the idea that this issue is not by-design, and there's something resolvable about it all.

For the memory footprint, I'm just using the "Memory (private working set)" statistic of the Windows Task Manager, to easily observe the different effects of different builds, 2.9.4 GCC being the outlier. I am still interested in keeping that number low, however, as the application I have in mind should be perceived by users as minimal resource use.

[Bob Paddock]

> S> Making this gives a memory footprint of 6,564K when window allowed to show.
> S> Timings for hacked OnInit:
> S>
> S> real 0m2.084s
> S> user 0m0.031s
> S> sys 0m0.016s
>
> I really can't explain this. Can anybody else reproduce these results?

I'm not sure what program those results are coming from?

One thing to watch for under Windows is that all directories in the
path actually exist.
If PATH contains a directory that is not really there, the program may
spend time searching the broken path until some timeout is reached.
I've never seen a number given for the time out value but I have had
it turn compiles that should take seconds in to compiles that take
minutes.

If Minimal is also searching a non-existent path trying to find DLLs
that may explain what is going on, why it does not show up cross
compiling nor on most other machines.

Si what happens if your force you PATH to only be what is required
from a DOS box and run Minimal from there?

Running the static Minimal sample with it returning false from OnInit
I see the frame flash on the screen. I do not see such a flash with
the DLL build.
The DLL build takes about two seconds to appear when OnInit returns
true. The static build takes less than a second to appear with OnInit
true.

Top few results of timing with ProcMon (with really bad formating due
to line wrap :-( ).

Using GCC 4.7.1 from http://nuwen.net/mingw.html on a quad core Win64
Windows 7 machine with 8G of RAM, I get the following using System
Internals ProcMon, with OnInit returning false. Sorted by duration
large to small, this is what I get:

DLL:
Time of Day Process Name PID Operation Path Result
Detail Relative Time Duration
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\Prefetch\MINIMAL.EXE-325451AB.pf NAME NOT FOUND
Desired Access: Generic Read, Disposition: Open, Options: Synchronous
IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a
00:10.1 0.0000762

05:53.6 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\ole32.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:11.2 0.0000691

05:53.6 minimal.exe 3356 RegQueryKey
HKLM\SOFTWARE\Microsoft\CTF\TIP SUCCESS Query: HandleTags, HandleTags:
0x400 00:11.2 0.0000614

05:52.5 minimal.exe 3356 CreateFile
C:\Windows\System32\wow64cpu.dll SUCCESS Desired Access: Read
Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open,
Options: Synchronous IO Non-Alert, Non-Directory File, Attributes:
n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:10.1 0.000043
05:52.5 minimal.exe 3356 CreateFile
J:\WX\294\lib\gcc_dll\wxbase294u_gcc_custom.dll SUCCESS Desired
Access: Read Data/List Directory, Execute/Traverse, Synchronize,
Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory
File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a,
OpenResult: Opened 00:10.1 0.0000373
05:52.5 minimal.exe 3356 CloseFile
C:\Windows\SysWOW64\sechost.dll SUCCESS 00:10.1 0.0000347
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\System32\wow64.dll SUCCESS Desired Access: Read Data/List
Directory, Execute/Traverse, Synchronize, Disposition: Open, Options:
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a,
ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:10.1 0.0000344
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\sechost.dll SUCCESS Desired Access: Read Data/List
Directory, Execute/Traverse, Synchronize, Disposition: Open, Options:
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a,
ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:10.1 0.0000335
05:53.6 minimal.exe 3356 CreateFile
C:\Windows\Fonts\StaticCache.dat SUCCESS Desired Access:
Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert,
Non-Directory File, Attributes: n/a, ShareMode: Read, Delete,
AllocationSize: n/a, OpenResult: Opened 00:11.2 0.0000331
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\System32\wow64win.dll SUCCESS Desired Access: Read
Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open,
Options: Synchronous IO Non-Alert, Non-Directory File, Attributes:
n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:10.1 0.0000312
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\WindowsShell.Manifest SUCCESS Desired Access:
Generic Read/Execute, Disposition: Open, Options: Synchronous IO
Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read,
Delete, AllocationSize: n/a, OpenResult: Opened 00:10.1 0.000029
05:53.6 minimal.exe 3356 CreateFile C:\Program Files
(x86)\McAfee\SiteAdvisor\saSets.ini SUCCESS Desired Access: Generic
Read, Disposition: Open, Options: Synchronous IO Non-Alert,
Non-Directory File, Attributes: n/a, ShareMode: Read, Write, Delete,
AllocationSize: n/a, OpenResult: Opened 00:11.2 0.0000287
05:53.6 minimal.exe 3356 CreateFile C:\Program Files
(x86)\McAfee\SiteAdvisor\sahook.dll SUCCESS Desired Access: Generic
Read, Disposition: Open, Options: Synchronous IO Non-Alert,
Non-Directory File, Attributes: n/a, ShareMode: Read, Delete,
AllocationSize: n/a, OpenResult: Opened 00:11.2 0.0000284
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\winspool.drv SUCCESS Desired Access: Read
Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open,
Options: Synchronous IO Non-Alert, Non-Directory File, Attributes:
n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:10.1 0.0000283
05:53.6 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\ole32.dll SUCCESS Desired Access: Read Data/List
Directory, Execute/Traverse, Synchronize, Disposition: Open, Options:
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a,
ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:11.2 0.0000283
05:53.6 minimal.exe 3356 QueryNameInformationFile
C:\Windows\SysWOW64\imm32.dll SUCCESS Name:
\Windows\SysWOW64\imm32.dll 00:11.2 0.0000268
05:52.5 minimal.exe 3356 CreateFile
J:\WX\294\lib\gcc_dll\wxmsw294u_core_gcc_custom.dll SUCCESS
Desired Access: Read Data/List Directory, Execute/Traverse,
Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert,
Non-Directory File, Attributes: n/a, ShareMode: Read, Delete,
AllocationSize: n/a, OpenResult: Opened 00:10.1 0.0000261
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\System32\wow64log.dll NAME NOT FOUND Desired
Access: Read Attributes, Disposition: Open, Options: Open Reparse
Point, Attributes: n/a, ShareMode: Read, Write, Delete,
AllocationSize: n/a 00:10.1 0.0000258
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\sechost.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:10.1 0.0000258
05:53.6 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\ole32.dll SUCCESS Desired Access: Read Data/List
Directory, Execute/Traverse, Synchronize, Disposition: Open, Options:
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a,
ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:11.2 0.0000258
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\System32\wow64cpu.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:10.1 0.0000245
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\System32\wow64win.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:10.1 0.0000242
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\wxbase294u_gcc_custom.dll NAME NOT FOUND
Desired Access: Read Attributes, Disposition: Open, Options: Open
Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete,
AllocationSize: n/a 00:10.1 0.0000242
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
SUCCESS Desired Access: Read Data/List Directory,
Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous
IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read,
Delete, AllocationSize: n/a, OpenResult: Opened 00:10.1 0.0000242
05:52.5 minimal.exe 3356 CloseFile
C:\Windows\System32\wow64cpu.dll SUCCESS 00:10.1
0.0000239
05:53.5 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\uxtheme.dll SUCCESS Desired Access: Read Data/List
Directory, Execute/Traverse, Synchronize, Disposition: Open, Options:
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a,
ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:11.1 0.0000239
05:52.5 minimal.exe 3356 CreateFile C:\Windows
SUCCESS Desired Access: Execute/Traverse, Synchronize, Disposition:
Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a,
ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
00:10.1 0.0000232
05:52.5 minimal.exe 3356 RegOpenKey
HKLM\System\CurrentControlSet\Control\Session Manager SUCCESS
Desired Access: Read 00:10.1 0.000023
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\System32\wow64.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:10.1 0.0000229
05:52.5 minimal.exe 3356 CreateFile
C:\Windows\SysWOW64\imm32.dll SUCCESS Desired Access: Read Data/List
Directory, Synchronize, Disposition: Open, Options: Synchronous IO
Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read,
Delete, AllocationSize: n/a, OpenResult: Opened 00:10.1 0.0000226
05:53.6 minimal.exe 3356 CreateFile C:\Program Files
(x86)\McAfee\SiteAdvisor\sahook.dll SUCCESS Desired Access: Read
Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open,
Options: Synchronous IO Non-Alert, Non-Directory File, Attributes:
n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:11.2 0.0000226

Static:
Time of Day Process Name PID Operation Path Result
Detail Relative Time Duration
08:19.1 minimal.exe 4048 RegEnumKey
HKLM\SOFTWARE\Microsoft\CTF\TIP SUCCESS Index: 4, Name:
{531FDEBF-9B4C-4A43-A2AA-960E8FCDC732} 00:03.1 0.0000854

08:19.0 minimal.exe 4048 CreateFile
C:\Windows\Prefetch\MINIMAL.EXE-0EBAAEBF.pf NAME NOT FOUND
Desired Access: Generic Read, Disposition: Open, Options: Synchronous
IO Non-Alert, Attributes: n/a, ShareMode: None, AllocationSize: n/a
00:03.0 0.0000793

08:19.0 minimal.exe 4048 CreateFile
C:\Windows\System32\wow64cpu.dll SUCCESS Desired Access: Read
Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open,
Options: Synchronous IO Non-Alert, Non-Directory File, Attributes:
n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:03.0 0.0000742

08:19.0 minimal.exe 4048 CreateFile
C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
SUCCESS Desired Access: Read Data/List Directory,
Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous
IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read,
Delete, AllocationSize: n/a, OpenResult: Opened 00:03.1 0.0000739
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\SysWOW64\sechost.dll SUCCESS Desired Access: Read Data/List
Directory, Execute/Traverse, Synchronize, Disposition: Open, Options:
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a,
ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:03.0 0.0000733
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\System32\wow64win.dll SUCCESS Desired Access: Read
Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open,
Options: Synchronous IO Non-Alert, Non-Directory File, Attributes:
n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:03.0 0.0000704
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\System32\wow64.dll SUCCESS Desired Access: Read Data/List
Directory, Execute/Traverse, Synchronize, Disposition: Open, Options:
Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a,
ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:03.0 0.0000656
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\System32\wow64cpu.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:03.0 0.0000564
08:19.0 minimal.exe 4048 CloseFile
C:\Windows\SysWOW64\sechost.dll SUCCESS 00:03.0 0.0000516
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\System32\wow64log.dll NAME NOT FOUND Desired
Access: Read Attributes, Disposition: Open, Options: Open Reparse
Point, Attributes: n/a, ShareMode: Read, Write, Delete,
AllocationSize: n/a 00:03.0 0.0000503
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\System32\wow64win.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:03.0 0.0000493
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\System32\wow64.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:03.0 0.0000481
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\SysWOW64\sechost.dll SUCCESS Desired Access: Read
Attributes, Disposition: Open, Options: Open Reparse Point,
Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a,
OpenResult: Opened 00:03.0 0.0000478
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll
SUCCESS Desired Access: Read Attributes, Disposition: Open,
Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write,
Delete, AllocationSize: n/a, OpenResult: Opened 00:03.1
0.0000468
08:19.1 minimal.exe 4048 CreateFile C:\Program Files
(x86)\McAfee\SiteAdvisor\saSets.ini SUCCESS Desired Access: Generic
Read, Disposition: Open, Options: Synchronous IO Non-Alert,
Non-Directory File, Attributes: n/a, ShareMode: Read, Write, Delete,
AllocationSize: n/a, OpenResult: Opened 00:03.1 0.0000442
08:19.1 minimal.exe 4048 CreateFile
C:\Windows\WindowsShell.Manifest SUCCESS Desired Access:
Generic Read/Execute, Disposition: Open, Options: Synchronous IO
Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read,
Delete, AllocationSize: n/a, OpenResult: Opened 00:03.1
0.0000436
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2
SUCCESS Desired Access: Read Attributes, Disposition: Open, Options:
Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete,
AllocationSize: n/a, OpenResult: Opened 00:03.1 0.0000433
08:19.0 minimal.exe 4048 CreateFile
C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2
SUCCESS Desired Access: Execute/Traverse, Synchronize, Disposition:
Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a,
ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
00:03.1 0.0000433
08:19.1 minimal.exe 4048 RegOpenKey
HKLM\SOFTWARE\Policies\Microsoft\Windows\App Management NAME NOT FOUND
Desired Access: Query Value 00:03.1 0.000043
08:19.0 minimal.exe 4048 CreateFile C:\Windows
SUCCESS Desired Access: Read Attributes, Synchronize, Disposition:
Open, Options: Synchronous IO Non-Alert, Attributes: n/a, ShareMode:
Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
00:03.0 0.0000427
08:19.0 minimal.exe 4048 CreateFile C:\Windows
SUCCESS Desired Access: Execute/Traverse, Synchronize, Disposition:
Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a,
ShareMode: Read, Write, AllocationSize: n/a, OpenResult: Opened
00:03.0 0.0000392
08:19.0 minimal.exe 4048 RegOpenKey
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Image
File Execution Options SUCCESS Desired Access: Query Value,
Enumerate Sub Keys 00:03.0 0.0000392
08:19.1 minimal.exe 4048 ReadFile C:\Program Files
(x86)\McAfee\SiteAdvisor\saSets.ini SUCCESS Offset: 0, Length:
1,518, Priority: Normal 00:03.1 0.0000383
08:19.1 minimal.exe 4048 CreateFile C:\Program Files
(x86)\McAfee\SiteAdvisor\sahook.dll SUCCESS Desired Access: Read
Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open,
Options: Synchronous IO Non-Alert, Non-Directory File, Attributes:
n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
00:03.1 0.0000376
08:19.0 minimal.exe 4048 CreateFile
J:\WX\294\samples\minimal SUCCESS Desired Access:
Execute/Traverse, Synchronize, Disposition: Open, Options: Directory,
Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write,
AllocationSize: n/a, OpenResult: Opened 00:03.0 0.0000373

[Si]

On Tuesday, August 7, 2012 3:43:09 PM UTC+2, wxwi...@gmail.com wrote:

Si what happens if your force you PATH to only be what is required
from a DOS box and run Minimal from there?

 

2 seconds start time (DLL version).

The DLL build takes about two seconds to appear when OnInit returns
true.  The static build takes less than a second to appear with OnInit
true.

2 seconds sounds significantly longer than 2.8.12, which starts quickly on even my Atom based machine.

[Si]

On Tuesday, August 7, 2012 11:06:43 AM UTC+2, Vadim Zeitlin wrote:

 I definitely don't see this here for the binaries cross-compiled from
Linux using MinGW 4.2.1. Even though the executable is ran from a network
(Samba) disk, it starts up in ~0.01s.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

Sadly, I'm not seeing any improvement from my cross-compiled version.

Arch Linux, up to date, MinGW-gcc 4.7.0-1 package with associated deps.

[Vadim Zeitlin]

On Tue, 7 Aug 2012 10:53:23 -0700 (PDT) Si wrote:

S> Sadly, I'm not seeing any improvement from my cross-compiled version.

This is really strange. Could you please try the binary from here:

https://docs.google.com/open?id=0BwsZEq2q2AodZW4tM1Q0aWdfUm8

Does it also start up slowly for you?

[Si]

That one's a winner, if it's a return false from OnInit compile - else it's silently crashing ;)

Runs in under 0.1s.

[Vadim Zeitlin]

On Tue, 7 Aug 2012 11:17:23 -0700 (PDT) Si wrote:

S> That one's a winner, if it's a return false from OnInit compile

Yes, it does. And it's compiled in release build, although actually
without any optimizations as I'm mostly interested in fast (re)builds, not
fast code. Here is the full configure command line:

% configure --host=i586-mingw32msvc --build=x86_64-unknown-linux-gnu \
--with-msw --disable-optimise

And here is the compiler used:

% i586-mingw32msvc-g++ -v
Using built-in specs.
Target: i586-mingw32msvc
Configured with: /home/ron/devel/debian/mingw32/mingw32-4.2.1.dfsg/build_dir/src/gcc-4.2.1-2-dfsg/configure -v --prefix=/usr --target=i586-mingw32msvc --enable-languages=c,c++ --enable-threads --enable-sjlj-exceptions --disable-multilib --enable-version-specific-runtime-libs
Thread model: win32
gcc version 4.2.1-sjlj (mingw32-2)

I have no idea why is it different from your build :-(

[Si]

Inspired by your penchant for antique compiler technology ;) , I've just installed the MinGW-5.1.6 collection (GCC 3.4.5!).

Wouldn't you know it...

[Si@CAEMLYN minimal]$ time gcc_mswudll/minimal

real    0m0.085s

user    0m0.030s

sys     0m0.030s

So, we've compiler issues where 2.9.x is concerned.

[Si]

Snappy startup time and 3,140K memory footprint for the wxHaskell bindings. Nice. It's only 1,832K for C++ minimal now.

[Si]

On Tuesday, August 7, 2012 9:01:14 PM UTC+2, Vadim Zeitlin wrote:

 I have no idea why is it different from your build :-(
VZ

OK, so taking compiler bundles from here:

http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/megasoft78/basic/ 

I can get a quick starting binary with 4.4.6, but not with the 4.5.2 version (same result as with the mingw-get version of gcc, with version constrained install).

It's difficult to narrow it down more, but I'm put in mind of your conversation here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601

Bah. Thoughts?

[Si]

On Tuesday, August 7, 2012 9:01:14 PM UTC+2, Vadim Zeitlin wrote:

 I have no idea why is it different from your build :-(
VZ

I 've been able to get a quick starter from TDM's GCC 4.5.2, which patches the dllexport problem.

I just had to remove the version check on the dlimpexp.h GNUC export handling before building, to get explicit exports again (as you mentioned before):

#    elif defined(__GNUC__)

I think it's just the GCC auto-loading that's funky.

Anyway, I failed to get results from 4.7.0 with this same change plus the no-keep-inline-dllexport flag that's supposed to give us back the 4.4 behaviour. Odd. Perhaps I've misunderstood the flag in my haste.

[Si]

On Tuesday, August 7, 2012 9:01:14 PM UTC+2, Vadim Zeitlin wrote:

 I have no idea why is it different from your build :-(
VZ

 

The plot thickens further. TDM's (current)  4.6.1-tdm-1 release works as advertised, which is very good news.

config.,gcc:

CPPFLAGS ?= -fno-keep-inline-dllexport

dlimpexp.h:

#        define WXEXPORT __declspec(dllexport)

#        define WXIMPORT __declspec(dllimport)

I'll have another crack at 4.7 later, using these same settings.

[Vadim Zeitlin]

On Thu, 9 Aug 2012 02:50:31 -0700 (PDT) Si wrote:

S> The plot thickens further. TDM's (current) 4.6.1-tdm-1 release works as
S> advertised, which is very good news.

Indeed. The bad news is that it requires modifying wxWidgets sources (to
enable the use of __declspec for it) as we can't distinguish between the
"real" MinGW (which doesn't work at all with __declspec since 4.6) and TDM
(which does and apparently still needs it). We'll probably need to add
makefile-level USE_AUTOEXPORT option or something like this...

Anyhow, please post here and/or open Trac ticket when you finally collect
all the information and can tell us which versions of the compiler work
[better] with autoexport and which ones without.

TIA,

[Eran Ifrah]

 I tried the suggested changes: 

1) changed dlimpexp.h so that the preprocessor will enter the suggested branch (to make sure that preprocessor "sees" the correct definition of WXEXPORT and WXIMPORT I confirmed it with #error preprocessor directives )

2) I modified config.gcc to include '-fno-keep-inline-dllexport'

3) I then tried to compile wx294 sources like this:

 mingw32-make -j4 -f makefile.gcc UNICODE=1 SHARED=1 BUILD=debug VENDOR=cl MONOLITHIC=1

and I ended up with (at linking stage):

gcc_mswuddll\monodll_tabart.o: file not recognized: Memory exhausted

collect2: ld returned 1 exit status

mingw32-make: *** [..\..\lib\gcc_dll\wxmsw294ud_gcc_cl.dll] Error 1

My system spec:

8 GB memory, Windows 7/64, GCC-TDM 4.6.1/32, i5-3550 

It does however work if I try to build it in a multilib configuration

--

Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users

--

Eran Ifrah
Author of the cross platform, open source C++ IDE: http://www.codelite.org

[Si]

I can't get the build characteristics I want from MinGW-get based GCC 4.6.1-2 or 4.7.0-1.

However, In addition to the latest TDM 4.6.1, I've been able to succeed with both 7.2 and 9.2 (without Git) from here http://nuwen.net/mingw.html, which have GCC 4.6.1 & 4.7.1 respectively.

No idea what the key common difference is between these other builds and the official ones.

I'm currently building just by removing the version guard in dlimpexp.h (__attribute__ works fine), and supplying:

(mingw32-)make -j 8 -f makefile.gcc CPPFLAGS=-fno-keep-inline-dllexport SHARED=1 BUILD=release

[Si]

On Thursday, August 9, 2012 5:18:32 PM UTC+2, eranif wrote:

 mingw32-make -j4 -f makefile.gcc UNICODE=1 SHARED=1 BUILD=debug VENDOR=cl MONOLITHIC=1

and I ended up with (at linking stage):

gcc_mswuddll\monodll_tabart.o: file not recognized: Memory exhausted

collect2: ld returned 1 exit status

mingw32-make: *** [..\..\lib\gcc_dll\wxmsw294ud_gcc_cl.dll] Error 1

My system spec:

8 GB memory, Windows 7/64, GCC-TDM 4.6.1/32, i5-3550 

Same here for that build config. The linker claimed up to a suspicious approximate 2GB of memory before crapping out, when there was plenty of real memory left (16GB on this system).

I see the ld help displays a flag "--large-address-aware" that refers to 2 gigabytes, so I guess MONOLITHIC is tripping over some limits in this config.

[Bob Paddock]

>> My system spec:
>> 8 GB memory, Windows 7/64, GCC-TDM 4.6.1/32, i5-3550
>
>
> Same here for that build config. The linker claimed up to a suspicious
> approximate 2GB of memory before crapping out, when there was plenty of real
> memory left (16GB on this system).

Have you tried any of the 64 bit builds like:
http://mingw-w64.sourceforge.net/

As a guess someplace they used a signed int in 32 bit space which
limits the symbol table to less than 2G.
Should have used size_t, to get at least 4G on 32 bits.

[Marian 'VooDooMan' Meravy]

Greetings,

On 10. 8. 2012 14:04, Bob Paddock wrote:
>>> My system spec:
>>> 8 GB memory, Windows 7/64, GCC-TDM 4.6.1/32, i5-3550
>>
>>
>> Same here for that build config. The linker claimed up to a suspicious
>> approximate 2GB of memory before crapping out, when there was plenty of real
>> memory left (16GB on this system).
>
> Have you tried any of the 64 bit builds like:
> http://mingw-w64.sourceforge.net/
>

Actually, to be more precise, my best guess is mingw32 is 32 bit binary,
which is restricted to use only 2 GiB RAM (unless you pass to Windows
boot loader options /3GB switch, AFAIK, this splits 32 bit addressing
space from 2/2 ratio: 2 GiB for userspace, 2 GiB for kernel virtual
address mapping; to ratio 3/1 ratio, respectively - though it IMO will
not be enough to build monolithic library as wx is large...). And my
best guess is mingw64 toolkit are 64-bit (x64/amd64) binaries, if so, it
is able to 'eat' your 8 GiBs + swap mapped memory, and virtually plenty
lots of GiBs.

> As a guess someplace they used a signed int in 32 bit space which
> limits the symbol table to less than 2G.
> Should have used size_t, to get at least 4G on 32 bits.
>

hmmm. If mingw64 is 64-bit binary, then size_t and pointers are 64-bit
wide, so it will be able to process lots of data.

best,
vdm
.

[Si]

On Thursday, August 9, 2012 2:21:23 PM UTC+2, Vadim Zeitlin wrote:

 Anyhow, please post here and/or open Trac ticket when you finally collect
all the information and can tell us which versions of the compiler work
[better] with autoexport and which ones without.

 TIA,
VZ

I'm not sure I can add much more, save to say that a clear build difference can be seen by using the TDM web install, and comparing his patched GCC 4.6.1 with the vanilla GCC 4.6.1 (both can be installed from it).

TDM's GCC produces the quick binaries with low memory footprint, and the vanilla GCC does not. And I'm led to believe that the rest of the tool chain is the same in both cases.

I've emailed both Stephan (http://nuwen.net) and TDM to ask for their opinions on which patches / configuration changes that they are including might produce this effect. Perhaps I'll get a reply that pulls everything into focus.

Well, I guess there are two issues in the end. One is that the 4.5 time/space issue with dlls is resolved with 4.6.1 + compiler flag in a general sense (though MONOLITHIC will be problematic, it's huge). The other is that something shonky has gone on with binary startup times and memory footprint, at some point after GCC 4.2.1 (as per your cross-compile, if your mingw compiler was unpatched). Explicit exports appear to be needed for fast load times in any case, but something else has changed too.

It's not clear to me why so few people appeared to notice issues like this with recent GCC versions, but it's clear that TDM and Stephan are patching in a way that reverses or ameliorates the issue. Long may that continue.

Si

[Si]

On Thursday, August 9, 2012 2:21:23 PM UTC+2, Vadim Zeitlin wrote:

 Anyhow, please post here and/or open Trac ticket when you finally collect
all the information and can tell us which versions of the compiler work
[better] with autoexport and which ones without.

 TIA,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

OK! The final piece of the puzzle is in.

John at TDM helped me to the realisation that the difference is:

LDFLAGS="-static-libstdc++ -static-libgcc"

His compiler distro builds with static libs by default, and also includes a shared memory mechanism for propagating exceptions out of DLLs without the need for shared versions.

Si

[Vadim Zeitlin]

On Fri, 10 Aug 2012 05:22:34 -0700 (PDT) Si wrote:

S> Well, I guess there are two issues in the end. One is that the 4.5
S> time/space issue with dlls is resolved with 4.6.1 + compiler flag in a
S> general sense (though MONOLITHIC will be problematic, it's huge). The other
S> is that something shonky has gone on with binary startup times and memory
S> footprint, at some point after GCC 4.2.1 (as per your cross-compile, if
S> your mingw compiler was unpatched). Explicit exports appear to be needed
S> for fast load times in any case, but something else has changed too.
...
S> OK! The final piece of the puzzle is in.
S>
S> John at TDM helped me to the realisation that the difference is:
S>
S> LDFLAGS="-static-libstdc++ -static-libgcc"
S>
S> His compiler distro builds with static libs by default, and also includes a
S> shared memory mechanism for propagating exceptions out of DLLs without the
S> need for shared versions.

Yes, I know this, but I don't see how could it explain the startup time
difference. I also still don't see any way out of this mess. Either we use
explicit dllexport and the build doesn't work with some gcc versions at all
or we use them and it works but the resulting binaries are extremely slow :-(

Regards,

[Eran Ifrah]

On the bright side, by the tips here:

1)  Modify config.gcc: CPPFLAGS ?= -fno-keep-inline-dllexport 

2) Remove the GCC version check in dlimpexp.h ( " !wxCHECK_GCC_VERSION(4, 5) ") from line ~36

3) Building wxWidgets as shared / *multilib* (monolithic results in ld memory exhaustion )

My application (codelite IDE), which has a large code base and uses ~30-40 dlls:

1) codelite's splash screen is now shown instantly (down from 12 seconds.. in release build) - note that the splash screen is created in the wxApp::OnInit

2) Debugging session starts faster (about 20 seconds, down from 1 min...) not as fast as linux but more "workable"

[Si]

On Friday, August 10, 2012 6:59:55 PM UTC+2, Vadim Zeitlin wrote:

 Yes, I know this, but I don't see how could it explain the startup time
difference. I also still don't see any way out of this mess. Either we use
explicit dllexport and the build doesn't work with some gcc versions at all
or we use them and it works but the resulting binaries are extremely slow :-(

 Regards,
VZ

I'm not sure I'm the best person to ask, as this issue is my only experience with GCC outside of seeing someone else's program compile occasionally.

Still, I'll guess at some things, and please correct any nonsense I spout here. As per:

http://mingw.org/wiki/GCCStatus

it's clear there have been ongoing problems related to exception handling and DLLs.

For GCC 3.4.5, a shared-memory approach was taken, and with static lib builds, everything started snappy.

Once the 4.x series finally shipped, in a sub-optimal state as they put it, SJLJ in combination with shared libs became the default strategy. This, despite stating on that page that "The old model, SJLJ, is no longer available". Clearly some backtracking going on, due to problems.

So, I think SJLJ represents the safe default until Dwarf exception model issues are ironed out. You'll get a working set of binaries / DLLs etc, but the shared libs and DLL relocation is not speedy for a project the size of WxWidgets. I think the startup delays seen are due to getting the system ready to throw exceptions across the various libs involved.

Three ways of improving that:

Configure vanilla GCC with LDFLAGS="-static-libstdc++ -static-libgcc". But there will be a problem if any exceptions are thrown out of the DLL.

TDM's 4.6.1-SJLJ. Re-introduce the shared memory approach, and build with static libs. Like above, but safe even when exceptions are thrown. It's basically bringing back the exception handling of 3.4.5 until something better is ready.

TDM's 4.6.1-DW2 or Stephan's (nuwen.net) builds. These use the new Dwarf exception model and also give speedy startup. But there are issues to be aware of that may or may not affect WxWidgets, related to unwinding the stack through non Dwarf objects, Windows callbacks etc.

To me, the TDM SJLJ compiler is a safe speedy option. I also like the DW2 idea, but really have no idea if WxWidgets can work correctly with it - and it is the direction things are going in.

Regarding WxWidgets changes, I like the idea of tightening up the GNUC version check so that only 4.5 is auto import/export, and including the no-keep-inline-dllexport flag. This is a problem for monolithic builds, but I can't help but feel that they currently work precisely because the real work is avoided. Perhaps one of the memory reduction flags will see ld successful with explicit import/exports.

I'll take a look at the default, static debug build today.

[Si]

On Friday, August 10, 2012 6:59:55 PM UTC+2, Vadim Zeitlin wrote:

 Yes, I know this, but I don't see how could it explain the startup time
difference. I also still don't see any way out of this mess. Either we use
explicit dllexport and the build doesn't work with some gcc versions at all
or we use them and it works but the resulting binaries are extremely slow :-(

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

It appears shared vs static is the problem for my static build tests, as my official MinGW GCC install actually uses dwarf2. I was not expecting to see that, but perhaps someone out there can confirm or deny that dwarf2 issues are resolved / have standard workarounds? In any case, it looks like the issue is the preparation of the shared lib environment at runtime.

TDM's default 4.6.1-sjlj + unmodified 2.9.4 static debug and release builds are both good. From now on, I characterise the quick starting executables as "good". I tested release builds only after this.

Vanilla GCC 4.6.1 needs LDFLAGS="-static-libstdc++  -static-libgcc" for a good executable (as does the latest 4.7.0).

Stephan's version 9.2 (4.7.1) at Nuwen also produces a good release. 

TDM uses static libs by default, vanilla is "--enable-shared", and Nuwen is "--disable-shared".

G++ configs follow.

TDM 4.6.1 sjlj:

Configured with: ../../src/gcc-4.6.1/configure --build=mingw32 --enable-languages=c,c++,ada,fortran,objc,obj-c++ --enable-threads=win32 --enable-libgomp --enable-lto --enable-fully-dynamic-string --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gnu-ld --disable-nls --disable-win32-registry --disable-symvers --disable-werror --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --enable-cxx-flags='-fno-function-sections -fno-data-sections' --with-pkgversion=tdm-1 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.tdragon.net/bugs

Thread model: win32

gcc version 4.6.1 (tdm-1)

mingw-get install gcc=4.6.1-2 g++=4.6.1-2 mingw32-make:

Configured with: ../gcc-4.6.1/configure --enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw

Thread model: win32

gcc version 4.6.1 (GCC)

Nuwen:

Configured with: ../src/configure --prefix=/c/temp/gcc/dest --with-gmp=/c/temp/gcc/gmp --with-mpfr=/c/temp/gcc/mpfr --with-mpc=/c/temp/gcc/mpc --enable-languages=c,c++ --with-arch=i686 --with-tune=generic --disable-libstdcxx-pch --disable-nls --disable-shared --disable-sjlj-exceptions --disable-win32-registry --enable-checking=release --enable-lto

Thread model: win32

gcc version 4.7.1 (GCC)

[Si]

On Saturday, August 11, 2012 9:01:28 AM UTC+2, eranif wrote:

On the bright side, by the tips here:

1)  Modify config.gcc: CPPFLAGS ?= -fno-keep-inline-dllexport 

2) Remove the GCC version check in dlimpexp.h ( " !wxCHECK_GCC_VERSION(4, 5) ") from line ~36

3) Building wxWidgets as shared / *multilib* (monolithic results in ld memory exhaustion )

My application (codelite IDE), which has a large code base and uses ~30-40 dlls:

1) codelite's splash screen is now shown instantly (down from 12 seconds.. in release build) - note that the splash screen is created in the wxApp::OnInit

2) Debugging session starts faster (about 20 seconds, down from 1 min...) not as fast as linux but more "workable"

I had no joy on a monolithic shared debug build, but could slip a release build under the 2GB limbo pole:

export CPPFLAGS="-fno-keep-inline-dllexport"

export LDFLAGS=-Wl,--reduce-memory-overheads,--no-keep-memory

export SHARED=1

export MONOLITHIC=1

export BUILD=release

LD hit about 1.8GB max in the process.