T3D 1.1 Plans for Project split in Libraries/DLL - RESOLVED
by Thomas · in Torque 3D Professional · 03/16/2011 (12:46 am) · 14 replies
Hi,
a question which whobbles (is this the correct word?) through my mind: Are there any projects to split the DLL project in project space in separate libraries, which could be linked together in a large DLL file afterwards?
On my machine the binding of the large DLL file consumes the most time on building step. I would expect that the binding of several lib files would be much faster than collecting all object files together and link them.
This would propably a great effort, due changes from toolbox to file structure would be necessary.
But these are just my 2cents!
a question which whobbles (is this the correct word?) through my mind: Are there any projects to split the DLL project in project space in separate libraries, which could be linked together in a large DLL file afterwards?
On my machine the binding of the large DLL file consumes the most time on building step. I would expect that the binding of several lib files would be much faster than collecting all object files together and link them.
This would propably a great effort, due changes from toolbox to file structure would be necessary.
But these are just my 2cents!
About the author
A guy from a farm, milking cows and driving tractors... Otherwise I run in burning houses and save some furniture lives...
#2
thanks for reply, interesting approach, I'll give it a go. Only problem will be then, that I need to modify the main function as well, but this doesn't cost much ;-)
I will return on this shortly, thanks!
EDIT:
Ok, linking is faster, but not the fastest at all, propably my machine is not fast enough...
03/16/2011 (2:53 am)
Hi Rene,thanks for reply, interesting approach, I'll give it a go. Only problem will be then, that I need to modify the main function as well, but this doesn't cost much ;-)
I will return on this shortly, thanks!
EDIT:
Ok, linking is faster, but not the fastest at all, propably my machine is not fast enough...
#3
03/16/2011 (3:04 pm)
The biggest speed up for compiling I can recommend is to disable the Browse Information generation (I forget the setting and I don't have Visual Studio to look it up). As far as I have been able to determine, it isn't used by anything/anyone and it can add a full minute to your builds.
#4
This setting is already disabled for VS2010 (there are bugs in VS2010 related to it since it is such a rarely used feature).
03/16/2011 (3:05 pm)
Quick followup:This setting is already disabled for VS2010 (there are bugs in VS2010 related to it since it is such a rarely used feature).
#5
sorry to raise my hand, but I use this feature often and extensively.
There might be people telling, that I'm blind in code, without the browse informations.
For me a good help to understand the work of the engine.
Maybe, I'm the only one in T3D universe... :-o
Last but not least, you're right, it's often annoying, waiting for this "Update Browse informations", huh, wait, I wouldn't get any coffee without this!
03/17/2011 (12:19 am)
Hi Matt,sorry to raise my hand, but I use this feature often and extensively.
There might be people telling, that I'm blind in code, without the browse informations.
For me a good help to understand the work of the engine.
Maybe, I'm the only one in T3D universe... :-o
Last but not least, you're right, it's often annoying, waiting for this "Update Browse informations", huh, wait, I wouldn't get any coffee without this!
#6
For my 2 core machine, 4 scales very well. More cores lead to more threads...
03/17/2011 (12:31 am)
Another hint, which I transferred from another library is to set the compiler flag /MPn with n the count of threads concurrently started. This gives you the power of multithreaded compilations.Quote:You can achieve this via Project Settings->Configuration->C/C++->Command line
Nothing more annoying than to wait for QT build on windows machines, whilst Linux users are developing already.
For my 2 core machine, 4 scales very well. More cores lead to more threads...
#7
Could you describe what *exactly* having the Browse Information generation turned on allows you to do? I spent a decent chunk of time turning it on and off and couldn't figure out how it was making a difference (Jump to Definition and the Object Browser still worked the same as far as I could tell). I was also unable to find any useful Microsoft documentation on it.
Thanks!
03/17/2011 (12:40 am)
Thomas,Could you describe what *exactly* having the Browse Information generation turned on allows you to do? I spent a decent chunk of time turning it on and off and couldn't figure out how it was making a difference (Jump to Definition and the Object Browser still worked the same as far as I could tell). I was also unable to find any useful Microsoft documentation on it.
Thanks!
#8
03/17/2011 (12:48 am)
Thanks Thomas! Changing /MP4 to /MP12 on my hex core almost halved the compile time on the DLL....
#9
sorry for your confusion, that was not my intent. I have checked without browse information setting, and tata, I'm able to browse the source.
I was lead by MS Link information, ok, it nowhere clearly tells me that browse informations are necessary. So obviosly MS lead me on the dark side of power.
03/17/2011 (1:54 am)
Hi Matt,sorry for your confusion, that was not my intent. I have checked without browse information setting, and tata, I'm able to browse the source.
I was lead by MS Link information, ok, it nowhere clearly tells me that browse informations are necessary. So obviosly MS lead me on the dark side of power.
#10
After reading through it carefully it seems like that prior to VS2005, you were dependent on the Browse Information generation if you wanted to use some of the useful Browse features (like Jump to Definition). Enabling this feature would cause it to generate .BSC files every time you compile and use those for Browsing.
According to the article, VS2005 and newer versions actually attempt to generate this Browse info on the fly from live source code (pre-compiling) and is not dependent on the .BSC files generated by setting the compiler flag which is causing the slow downs.
They do mention that there are a few limitations to the Live Source Browsing but they don't cover which ones are limitations unique to Live Source Browsing as opposed to limitations to both Live and compile-time Source Browsing. They also implied that, given time, they had a plan to fix those limitations for Live Source Browsing.
Given that we are 3 versions and 5 years further down the road, I wouldn't be surprised if they had fixed those limitations by now =)
I *think* that the compiler generated Browse Information (.BSC) is an outdated and unneeded feature with newer versions of Visual Studio (which would explain why Microsoft hasn't fixed the VS2010 bugs in it yet). Given that it adds a *lot* of overhead to your compile times, I would recommend unsetting that option in your solutions.
Hopefully someone over at GG (Tom?) can update the Project Generator templates to remove this from the VS2008 templates also =)
03/17/2011 (2:38 pm)
Actually that article has some very good info in it =)After reading through it carefully it seems like that prior to VS2005, you were dependent on the Browse Information generation if you wanted to use some of the useful Browse features (like Jump to Definition). Enabling this feature would cause it to generate .BSC files every time you compile and use those for Browsing.
According to the article, VS2005 and newer versions actually attempt to generate this Browse info on the fly from live source code (pre-compiling) and is not dependent on the .BSC files generated by setting the compiler flag which is causing the slow downs.
They do mention that there are a few limitations to the Live Source Browsing but they don't cover which ones are limitations unique to Live Source Browsing as opposed to limitations to both Live and compile-time Source Browsing. They also implied that, given time, they had a plan to fix those limitations for Live Source Browsing.
Given that we are 3 versions and 5 years further down the road, I wouldn't be surprised if they had fixed those limitations by now =)
I *think* that the compiler generated Browse Information (.BSC) is an outdated and unneeded feature with newer versions of Visual Studio (which would explain why Microsoft hasn't fixed the VS2010 bugs in it yet). Given that it adds a *lot* of overhead to your compile times, I would recommend unsetting that option in your solutions.
Hopefully someone over at GG (Tom?) can update the Project Generator templates to remove this from the VS2008 templates also =)
#12
03/17/2011 (7:51 pm)
Great!
#13
03/19/2011 (12:27 am)
So Ray looked into this today. Seems that Matt disabled it a few months back already... so this is changed and will be in the final 1.1 release. 
#14
04/24/2011 (4:23 pm)
Fixed in 1.1 Final and Preview. 
Associate Rene Damm