On Sep 28, 6:56 pm, "e. roman" <[EMAIL PROTECTED]> wrote:
> Link time is a killer. There is no silver bullet, but these help:
>
> (1) Defrag harddisk(s) daily.http://support.microsoft.com/kb/555098
> The intermediary build files can become fragmented and really slow things
> down.
I have to do this more often.
> (2) Use a separate hard disk from your system disk to build the code on.
> (I was dubious this would help, but it actually makes a noticeable
> difference on Windows).
Generally is can help, but it depends. We have all source code on a
fast network drive and I originally download the chrome trunk here.
The compiling was terribly slow. The linking was abouit the same I see
now, but moving it to the local drive help the compiling - by hours.
> (3) Only build the components you need -- avoid "Build solution" like
> the plague.
trust me, I tried this approach as I do with all my large
projects. :-)
> If you are debugging chrome, right click and build chrome_exe project only.
Actually, you are building the DLL, but sure, using the IDE is all
known. Been using Microsoft IDEs since their original Programmer
Workbench in the 80's and Borlands IDE's as well since those days. I
am familar with the project workspace environment and its short cuts.
> If you are working in backend modules, only build the associated
> unit-tests and start your work there.
I started to this.
> If you can, use test_shell.exe in place of chrome.exe, do so, as it
> builds faster (good for testing webkit/glue stuff)
Test_Shell.exe? I will look into that.
> If you are working on a backend module like net/ and base/ you have it
> good, as this modules build in isolation, and you can do development
> almost entirely targetting the unit-tests (and hence not link
> chrome.dll until you are ready for functional/integration testing).
Yes, I will have to do this more and more importantly get back to
using my long time power programmer editor.
> There was talk in the past of breaking debug builds into multiple
> DLLs, to mitigate link times.
> M-A did some investigation -- I don't recall the exact conclusion, but
> it was deemed not worth pursuing.
Separating the DLL (by functionality) would be a project design
decision for project managment, run time, distribution and support
considerationsl.
Unfortunately, once people are setup and comfortable, who cares of
other's people problems? <g> I just find it fascinating that I have
to now look into getting a "monster" machine just for Chrome VS-based
development,
Other considerations are:
- Workstation vs Server machine
- Consider enabling the "Server" I/O priority over UI.
Right Click My Computer | Advanced | Performance | Advanced
This will kill your desktop I/O, so minimize the IDE and only do this
for complete builds.
- Consider turning off the XP/Vista advanced graphics, this will
drastically speed up the desktop I/O, brings it down to NT/2000 gui
levels.
Right Click My Computer | Advanced | Performance | Visual
Effects
Finally, look at your memory load when building chrome on your
machine. This program will display it you:
// File: V:\bin\memload.cpp
// compile with: cl memload.cpp /MD /D "_AFXDLL"
#include <windows.h>
#include <stdio.h>
void main(char argc, char *argv[])
{
MEMORYSTATUS ms;
ms.dwLength = sizeof(ms);
GlobalMemoryStatus(&ms);
printf("Memory Load: %d%%",ms.dwMemoryLoad);
}
The Memory load is a factor that combines everything about the machne
memory I/O, disk, graphics, caching, paging etc. The higher this
number the poorer your system is for Chrome. The lower the more
optimal your machine.
For my personal XP/PRO box, I am at 85-90% when building Chrome. It
means, I need more memory or faster hard drives, etc. I normally use
my W2K Box which is a monster development box. I was going to try to
restructure the chrome project so I can compile from this box.
Anyway, thanks for the tips for the isolation builds.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Chromium-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/chromium-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
