As a follow up, I would suggest the mentioned MemoryLoad.cpp utility
be posted at the Chromes Windows Building Web site to give potential
developers an initial feel to see they are going to have building/
performance problems.
We show the memory load for our product server status page, and it
helps a lot in providing customers a feel on how well their system is
suited for our high-end product RPC client/server operations. Its
normally the first thing asked by support when someone reports a
"things are slow" incident.
As a long time windows development shop, my personal obversation over
the years is that things started to get slow (obviously) as Microsoft
began to "Glorirfy" the graphics with 95 based, then XP and now Vista
OSes.
The better machines for development and/or server operations have been
the non 95 based OSes
NT, 2000, 2003, and now 2008
but unfortunately, even 2008 has gotten the "longhorn" vista crap so
its slow as well.
Look at your memory load when things are stable (nothing applet
running on the desktop) to get a good feel for the baseline
performance expectation. Even consider temporarily stopping some
services to see how the memory load changes. Then begin to compare
the memory load as you begin to load chrome.sln under vstudio and
begin compiling. If its high, the machine is really not optimal for
this chrome project.
Just a consideration.
--
HLS
On Sep 28, 11:51 pm, HLS <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
