kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 8/4/2011 2:37 PM, jean-pierre charras wrote:
> Le 04/08/2011 20:10, Wayne Stambaugh a écrit :
>> On 8/4/2011 5:09 AM, Brian Sidebotham wrote:
>>> On 4 August 2011 03:25, Dick Hollenbeck<dick@xxxxxxxxxxx>  wrote:
>>>>
>>>>> (My machine compiles the entire Kicad source in 3 mins 30 seconds, on Ubuntu
>>>>> x86_64, no wxWidgets, just Kicad.)
>>>>
>>>> $ make clean
>>>>
>>>> $ time make -j 5
>>>>
>>>> real    3m0.329s
>>>>
>>>> Looks more like 3 minutes flat.
>>>>
>>>> But I compile for a living.
>>>>
>>>
>>> Nice! On windows mingw32-make cannot run multiple jobs without
>>> crashing so it is really limited; Annoying as I bought a quad core
>>> processer with hyper threading for mingw32-make -j 7
>>>
>>> D'oh!
>>>
>>> I am passing -DCMAKE_BUILD_TYPE=Release through to the KiCad build. I
>>> expect it is still generating "debug" symbols though. I will have
>>> another look tonight anyway and see what conclusions I can reach.
>>
>> I checked the release build on my machine and found the same thing.  Running
>> "strip --strip-all" made no difference in the size of eeschema.exe (11617280
>> bytes).  It may just be that the static link version of wxWidgets (I'm using
>> 2.9.2) is the culprit.  Maybe it's time to start building and linking to
>> wxWidgets dynamically instead of statically.  This appears to be the way MinGW
>> is heading judging by the dynamic libraries installed with GCC 4.5.2 (the
>> default compiler when installing MinGW using mingw-get).  I see no problem
>> linking dynamically other than making sure all the required library
>> dependencies are included when running "make install" and/or creating the
>> Windows installer.
>>
>> Wayne
>>
> 
> I also made some tests.
> 
> I can confirm tests made by Wayne.
> But I am not sure the dynamic link solves the main issue: time to see the Kicad
> window on screen.
> I compiled Kicad using wxMSW 2.8.12 (the last stable version) and wxWidgets
> 2.9.3 ( the SVN version)
> under gcc 4.4 and 4.5.2
> 
> With the same compiler version, Kicad binaries, and wxWidgets libs
> with 2.8.12 have a size that is roughly half the size of the 2.9.3 version.
> 
> On my computer Eeschema is shown on screen about 2 seconds after launching the
> binary, with 2.8 version.
> With 2.9.3 Eeschema is shown on screen about 8 seconds or more after launching
> the binary, with 2.9 version.
> 
> Note when compiled with gcc 4.4, Eeschema (and other kicad applications) is
> shown on screen faster.
> 
> I am afraid this issue could be due to the fact wxWidgets has no more a debug
> and a release version,
> but only an unique version.

The problem appears to be due to this:

http://docs.wxwidgets.org/trunk/overview_debugging.html

If I am reading this correctly, the wxWidgets assertion macros no longer
compile away on release builds.  They also add a extra layer of complexity by
checking the value wxDEBUG_LEVEL to determine if the assertion should be
raised.  This has the potential to also affect performance.  On my machine
there is a noticeable performance hit when loading the video sample board with
PCBNew.  It appears that in order to make the assertions compile away,
wDEBUG_LEVEL must be set to 0 by using the --disable-debug configure option
when building wxWidgets.  Here are the file size improvements:

bitmap2component.exe   5897728       4482560
cvpcb.exe              8552960       6952960
eeschema.exe           11617280      9842176
gerbview.exe           8982528       7319040
kicad.exe              7520768       6028288
pcbnew.exe             13618176      11782144

It's not obvious that --disable-debug is required to make the debugging macros
compile out of the release version of the wxWidgets library.  I had to dig
around the configure.in file to figure this out.  Hopefully this will be more
clearly documented by the time wxWidgets 3.0 is released.  Maybe combining this
with the GCC flags Brian suggested will further improve the file sizes.

Wayne

> 
> If this is the case, this is a bad news.
> 
> I also am afraid the use of dynamic libraries add more time to launch Kicad.
> It fixes only the size of binaries, that is now a very minor problem.
> 
> By the way, the SVN version works fine for me and has fixed annoying issues
> found in Kicad.
>