Re: Multi Threading Options

On Thu, 2 Jun 2005 04:28:36 +0100, Mark Randall wrote:

> The 3 main extern's in my list are:
>
> CBot - The main controller for the application handling the 3rd party SDK
> CAwAvatars - The collection of the avatar objects, and the searching
> functions (PS: The average count of items in it is usually below 40)
> CZoneManager - A large interface for a geographical area defenitions,
> polygons etc.
>
> I have no idea why it is compiling so slow then anyway...
>
> ------ Build started: Project: EclipseEvolution, Configuration: Debug
> Win32 ------
> Compiling...
> stdafx.cpp
> Compiling...
> CountArray.cpp
> xmlmanager.cpp
> ZoneManager.cpp
> Zone.cpp
> MIFI_GraphicChart.cpp
> CMIFI_2DGround.cpp
> 2DGround_ObjectMaps.cpp
> 2DGround_KeyControl.cpp
> 2DGround_Compass.cpp
> 2DGround_AxisControl.cpp
> MIF_AvatarsKeys.cpp
> MIF_Avatars.cpp
> mif_Text.cpp
> mif_SelectObject.cpp
> mif_Rectangles.cpp
> mif_Polygons.cpp
> mif_Pens.cpp
> mif_Lines.cpp
> mif_Circles.cpp
> MapIFBase.cpp
> Generating Code...
> Compiling...
> MapDialog.cpp
> MapIF_GraphTracker.cpp
> MapIF_GraphChat.cpp
> MapIF_Avatar.cpp
> MapIF.cpp
> awCore_AntiSeekerProperties.cpp
> awCore_AntiSeeker.cpp
> AwCore_VersionLock.cpp
> AwCore_IPNotify.cpp
> AwCore_Follow.cpp
> AwCore_NoCaps.cpp
> awCore_BannedIP.cpp
> awCore_AddressList.cpp
> WorldRights.cpp
> awCore_Greetings.cpp
> LoginProfileCollection.cpp
> LoginDlg.cpp
> cisWorldRights.cpp
> cisGUIData.cpp
> cisExecutionSequencers.cpp
> Generating Code...
> Compiling...
> cisEjections.cpp
> cisDispatch.cpp
> cisChatOutput.cpp
> cisBotTeleport.cpp
> cisBotInformation.cpp
> cisBotChanges.cpp
> cisAvatarWarp.cpp
> MD5Checksum.cpp
> Coordinates.cpp
> IEvtMgr.cpp
> PrivilegeResolver.cpp
> CoreCitizenResolver.cpp
> CoreCitizenLookupMgr.cpp
> DNSLookupMgr.cpp
> TreeCtrlEx.cpp
> DRSAddNewUserDlg.cpp
> RightsMgrDlg.cpp
> DynamicRights.cpp
> BotConnect.cpp
> Bot.cpp
> Generating Code...
> Compiling...
> awBot_World.cpp
> awBot_RcConverter.cpp
> awBot_Properties.cpp
> awBot_OutputMethods.cpp
> awBot_Initialisation.cpp
> awBot_GetData.cpp
> awBot_EnterExit.cpp
> awBot_ConnectionStates.cpp
> awBot_Botgrams.cpp
> World.cpp
> awWorld_SkyColours.cpp
> awCallback_Login.cpp
> awCallback_Enter.cpp
> awCallback_AvatarAddress.cpp
> citizen_resolve.cpp
> awEvent_WorldDisconnect.cpp
> awEvent_WorldAttributes.cpp
> awEvent_URL.cpp
> awEvent_UniDisconnect.cpp
> awEvent_Teleport.cpp
> Generating Code...
> Compiling...
> awEvent_ConsoleMsg.cpp
> awEvent_Chat.cpp
> awEvent_Botgram.cpp
> awEvent_AvatarDelete.cpp
> awEvent_AvatarChange.cpp
> awEvent_AvatarAdd.cpp
> awAvatar_Zoning.cpp
> awAvatar_Security.cpp
> awAvatar_Reporting.cpp
> awAvatar_Privileges.cpp
> awAvatar_Messages.cpp
> awAvatar_ListIcons.cpp
> awAvatar_DataMiner.cpp
> awAvatar_Constructor.cpp
> awAvatar_CapsCheck.cpp
> awAvatar_BuildStates.cpp
> AwAvatar.cpp
> awAvatars_UserCounts.cpp
> awAvatars_NotifyStreams.cpp
> AwAvatars.cpp
> Generating Code...
> Compiling...
> rptBldr_Universe.cpp
> rptBldr_CoreInfo.cpp
> rptBldr_ByUserType.cpp
> ReportBuilder.cpp
> ListCtrlStyled.cpp
> AvatarDisplayDlg.cpp
> patterns.cpp
> evo_database.cpp
> Redirect.cpp
> api_std.cpp
> globals.cpp
> Joystick.cpp
> EclipseEvolution.cpp
> PrivateMessageDlg.cpp
> WorldEjectDlg.cpp
> SelectAvatarsDlg.cpp
> BotgramDlg.cpp
> ConsoleMessageDlg.cpp
> SelectDropdownDlg.cpp
> EjectUserDlg.cpp
> Generating Code...
> Compiling...
> InputSysExDlg.cpp
> EditExtended.cpp
> MultilineInputBoxDlg.cpp
> InputBoxDlg.cpp
> LocationDlg.cpp
> WhisperDlg.cpp
> ConfigFrameDlg.cpp
> WorldDlg.cpp
> EditBox.cpp
> ConfigDlg_Section.cpp
> ConfigDlg_Node.cpp
> ConfigDlg_Master.cpp
> PropertiesTree.cpp
> AboutDlg.cpp
> WorldRightsDlg.cpp
> ReportFrame.cpp
> MappingDlg.cpp
> IndicatorPane.cpp
> c:\Documents and Settings\Mark\Desktop\Eclipse
> Evolution\IndicatorPane.cpp(66) : warning C4312: 'type cast' : conversion
> from 'UINT' to 'HWND' of greater size
> ColourPane.cpp
> ColourButton.cpp
> Generating Code...
> Compiling...
> evoDlg_ShellAPI.cpp
> evoDlg_OnLoad.cpp
> evoDlg_MessageMap.cpp
> evoDlg_MenuManipulation.cpp
> evoDlg_DoDataExchange.cpp
> EclipseEvolutionDlg_Write.cpp
> EclipseEvolutionDlg.cpp
> AvatarDBDlg.cpp
> evoDlg_OnSize.cpp
> MYDerrivision.cpp
> Generating Code...
> Compiling resources...
> Linking...
> Creating library Debug/EVOAPP2.lib and object Debug/EVOAPP2.exp
> Build log was saved at "file://c:\Documents and
> Settings\Mark\Desktop\Eclipse Evolution\Debug\BuildLog.htm"
> EclipseEvolution - 0 error(s), 1 warning(s)
>
> ---------------------- Done ----------------------
> Build: 1 succeeded, 0 failed, 0 skipped
>
> Execution Time: 1 minute 42 seconds, of that 8 seconds was creating the PCH,
> a 1.8Ghz P4 with 3/4 of a GB of RAM. Total Lines: Approx 26,000.

Where did it seem to be spending the rest of its time?

> The app is a total solution anyway, its never meant to have bits and bobs
> taken from it as its all so intercombined.

You have a fair number of files there. I've talked before about the
relationship between file count and build times, so I'll quote from a
couple of past messages below. The sad thing is, if per-file overhead is
the reason your builds are taking longer that you want, you're going to
have to reorganize, which means merging files (bad for organization) or
figuring out a way to decrease this overhead. At the very least, check the
things Alexander G mentioned.

http://groups-beta.google.com/group/microsoft.public.vc.language/msg/855f8210737524a5?hl=en
<q>
That depends on what the overhead is to compile each file. If there's a
fixed overhead equal to N seconds per file, and you have a 1,000 line
source file that takes N+X seconds to compile, splitting it into 10 roughly
equal parts yields a total compile time of 10N+X and a per-file compile
time of N+X/10. If X << N, and N is noticeably large, then you've achieved
an insignificant gain in per-file compile times at the expense of ruining
full builds. In cases like this, it's no more expensive to compile the
entire original 1,000 line source file than it is to compile any one of the
"optimized" 100 line files, and splitting the original file hurts. In fact,
it can be a big win to merge files.

I gave a simple example of this at the end of this message:

http://groups-beta.google.com/group/microsoft.public.vc.mfc/msg/318a72dcce97967a

As I said toward the end of that 2002 message, " I've observed a similar
phenomenon when using large precompiled headers and templates, but that's
not so easy to demonstrate in a newsgroup post. However, it's what
initially led me to look at this, roughly seven years ago." With faster
machines, this is much less of a problem than it used to be, at least for
relatively small projects. That is, N may remain much larger than X, but
for sufficiently small N, it ceases to matter.
</q>

For a dramatic example of how merging files can be an incredibly huge win:

http://groups-beta.google.com/group/microsoft.public.vc.mfc/msg/318a72dcce97967a
<q>
Suppose you're writing a Windows library.
Every file needs to #include <windows.h>. Precompiled headers are not
available. Your files look like:

f1.cpp:

#include <windows.h>

void f1() {}

f2.cpp:

#include <windows.h>

void f2() {}

f3.cpp:

#include <windows.h>

void f3() {}

Using VC6 on an old 200 MHz machine, the command:

cl -c f1.cpp

takes 5 sec. The command:

cl -c f1.cpp f2.cpp f3.cpp

takes 16 sec.

Now merge f2.cpp and f3.cpp into f1.cpp, so we have:

#include <windows.h>

void f1() {}
void f2() {}
void f3() {}

Unsurprisingly, the command:

cl -c f1.cpp

still takes 5 sec. This result holds as the functions grow to hundreds
of lines each (and actually use the Windows API), depending on the
complexity of the code, of course. Note that if only two of these
files needed to be compiled due to some (unshown) header they depend
on changing, it would still be a big win to compile the composite f1
instead of compiling them individually. And if only one of them needed
to be compiled, you don't lose anything by compiling the composite
file. This is what I mean by the per-file overhead dominating the
compilation time. When this is the case, it may be no more expensive
to compile many hundreds of lines than it is to compile one line, up
to a point. As I've said, I've observed a similar phenomenon when
using large precompiled headers and templates, but that's not so easy
to demonstrate in a newsgroup post. However, it's what initially led
me to look at this, roughly seven years ago.
</q>

--
Doug Harrison
Microsoft MVP - Visual C++
.

Loading