Andreas Zieringer wrote:
> Hi Marcus,
>
>   
Thanks for explaining things, Andreas. I realize I didn't know as much 
about the build system as I ought to, before making such broad 
suggestions, etc.  Your patience is appreciated. :)
>> Hi,
>>
>> I've been compiling OpenSG 1.8 a couple of times now, and found a few 
>> small issues that I think could be improved:
>>
>> Use -O in the scons.bat file? (optimize python code)
>>     
> hmm cool didn't know about this option could you measure any speed 
> improvement?
>   
I didn't measure, but I suppose I could. Most of it is disc-access and 
so on. Compile times are still large, but every little bit helps I 
suppose. :)
>> Using /Zi instead of /Z7 works and produces smaller obj files. This puts 
>> intermediate debuginfo in a vc70.idb/pdb file in the cvs root dir. On 
>> link, it creates per-target pdb-files as usual. It seems to be working 
>> even though debug/release builds use the same intermediate files.
>>     
> interesting but this won't work with -j 2. Is there any speed difference 
> while creating the pdb files?
>   
I didn't know that -j X worked with the visual studio compiler at all. 
But perhaps it's just with pdb-s then. This means I could do -j 4 on my 
computer at work. Yay! (dual dual-core. :)

Anyway, the OBJ-files are about half the size when using PDB's (similar 
to no-debug-info), so I assumed that to be a big improvement (There is 
still 750 mb data to link for OSGSystem). I should of course back this 
up with solid timing numbers, but it takes a lot of time to compile. It 
might be that it's offset by the ability to run parallell jobs.

I'll try to run some timings to see if this actually is a good thing or 
not. (Perhaps you'd want to use pdb's on single-cores but not on 
multi-cores).

The problem is that I can't profile properly, as I'm using my machine at 
the same time.

>> Always using /DEBUG as link flag (to create debug). There's really no 
>> need for the dbgopt version, as the outputted files are pretty 
>> equivalent (by ignoring the PDB's, dbgopt is equivalent to opt)
>>     
> possible but this creates always pdb files and this is really very slow 
> and needs much harddisk space so I like to keep the special dbgopt build.
>   
Hm. PDB's don't consume that much harddisk space compared to everything 
else. It's 750 mb of obj and ~40-50 mb of pdb. The obj-files don't 
increase due to pdb. You do get an extra vc70.idb/.pdb-file, which are 
15 mb total after compiling everything.
>> Change /FORCE:MULTIPLE (not needed) to /INCREMENTAL:NO (needed due to an 
>> internal linker limit being reached by OSGSystem).
>>     
> I added the /FORCE:MULTIPLE to get rid of multiple defined symbol errors 
> while linking the OSGWindowQT.lib are this errors fixed with 
> /INCREMENTAL:NO?
>   
Ah. I don't compile with QT, it works for the other win32-libs. Perhaps 
use it only on the QT lib then? (I get a bit nervous just by seeing that 
linker option. :-)
>> Always define OSG_DEBUG_FCPTR for debug-versions? It doesn't impact perf 
>> that much and is a great help. Add check to make sure client & lib is 
>> compiled with same source?
>>     
>
> hmm yes this option is quite nice but a ugly HACK. If we add the define 
> to the auto created OSGConfigured.h file we can eliminate any conflicts.
>   
> ups I confused this with the OSG_INVALID_PTR_CHECK define, 
> OSG_DEBUG_FCPTR just helps the debugger a bit.
>   
Yup. But it took me 1,5 years to discover that it existed and get to the 
point where I could compile OpenSG myself (with that switch enabled). It 
was a pain to debug before that. Therefore I think that enabling it by 
default would help new users who want to debug their code.

Cheers,
/Marcus


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to