f you don't compile Chrome under Windows, feel free to ignore this e-mail.
Summary: use a separate disk to host Chrome source and reduce VC concurrent job count to (number of physical cores - 1) from default (number of logical cores) reduces compilation time on my machine from 1:23:15 to 49:30 (40.5% speed up)
Machine configuration: Dell Precision T3500, Xeon X5...@2.67 GHz, 12GB of RAM, initially 500GB SATA HD, BitLock disabled Windows 7 Enterprise Visual Studio 2008 SP1
Observations:
- By default, VC sets number of logical cores as max number of parallel project builds (Tools->Options->Project and Solutions->Build and Run). In my case, it's 12 (6 physical cores and hyper thread) - The "max number of parallel project builds" is actually number of VCBuildHelper.exe instances, not the number of concurrent cl.exe. Similar things happened in VC 2010: this number indicates number of MSBuild.exe instances, not cl.exe. See attached picture. - Also, each link.exe in the picture is committing high amount of memory (~1G each) and thus 12 instance will invite very high page fault counts. - mspdbsrv.exe is the service that synchronize and generate pdb usage during compile time. It's also obvious from the picture that this is the single bottleneck of compilation speed (high I/O bytes, high memory usage (the working set), ridiculous page fault counts).
[image: Capture-cl.PNG]
Countermeasures:
- To handle mspdbsrv.exe issue, we need to separate the swap from source so that the I/O and page fault pressure can be separated into two different I/O channels (in my case, a different SATA port). This is solved by adding a new disk to the system and make sure it's not used for swap. (Control Panel->System and Security->System->Advanced->Performance/Settings->Advanced->Virtual memory/Change) - Reduce the pressure of Windows Virtual Memory manager by reducing concurrent jobs. In my case, 5 (number of physical cores - 1) is taken from rules of thumb. It may not be optimal but works very well in my case.
Actual results:
Time required to build chrome.sln (DEBUG|Win32) reduced from 1:23:15 to 49:30.
On Mon, Apr 11, 2011 at 2:42 PM, Arthur Hsu <arthur...@chromium.org> wrote: > Summary: use a separate disk to host Chrome source and reduce VC concurrent > job count to (number of physical cores - 1) from default (number of logical > cores) reduces compilation time on my machine from 1:23:15 to 49:30 (40.5% > speed up)
Currently http://dev.chromium.org/developers/how-tos/build-instructions-windows instructs people to reduce the number of parallel builds based on available RAM and suggests 8 builds for 12 GB. I'm currently using 6 for my Z600 with 12 GB. Perhaps this number needs more adjusting or perhaps your and my values are slightly too low.
8 builds for 12GB might be a bit bold. Worst case is 8 linkers each takes ~1G of RAM, and thus only 4G to spare to the rest of system. Unfortunately, mspdbsrv is not that well behaved and it might take another 2 to 4G, leaving rest of the system underwater.
The other thing to consider is the number of cl.exe spawned. In my first test, I've spotted over 100 cl.exe instances being created when the number is set to 10. The picture is not captured because I'm not that fast at clipping the screenshot and the system was not responsive, either. Anyway lots of CPU cycles will be wasted for context switching among that many cl.exe instances and thus we shall drive the number to a lower range (e.g. 5 or 6).
-Arthur
On Mon, Apr 11, 2011 at 2:47 PM, Peter Kasting <pkast...@chromium.org>wrote:
> On Mon, Apr 11, 2011 at 2:42 PM, Arthur Hsu <arthur...@chromium.org>wrote:
>> Summary: use a separate disk to host Chrome source and reduce VC >> concurrent job count to (number of physical cores - 1) from default (number >> of logical cores) reduces compilation time on my machine from 1:23:15 to >> 49:30 (40.5% speed up)
> Currently > http://dev.chromium.org/developers/how-tos/build-instructions-windows instructs > people to reduce the number of parallel builds based on available RAM and > suggests 8 builds for 12 GB. I'm currently using 6 for my Z600 with 12 GB. > Perhaps this number needs more adjusting or perhaps your and my values are > slightly too low.
On Mon, Apr 11, 2011 at 2:42 PM, Arthur Hsu <arthur...@chromium.org> wrote: > f you don't compile Chrome under Windows, feel free to ignore this e-mail.
> Summary: use a separate disk to host Chrome source and reduce VC concurrent > job count to (number of physical cores - 1) from default (number of logical > cores) reduces compilation time on my machine from 1:23:15 to 49:30 (40.5% > speed up)
> Machine configuration: > Dell Precision T3500, Xeon X5...@2.67 GHz, 12GB of RAM, initially 500GB > SATA HD, BitLock disabled > Windows 7 Enterprise > Visual Studio 2008 SP1
> Observations:
> - By default, VC sets number of logical cores as max number of parallel > project builds (Tools->Options->Project and Solutions->Build and Run). In > my case, it's 12 (6 physical cores and hyper thread) > - The "max number of parallel project builds" is actually number of > VCBuildHelper.exe instances, not the number of concurrent cl.exe. Similar > things happened in VC 2010: this number indicates number of MSBuild.exe > instances, not cl.exe. See attached picture. > - Also, each link.exe in the picture is committing high amount of > memory (~1G each) and thus 12 instance will invite very high page fault > counts. > - mspdbsrv.exe is the service that synchronize and generate pdb > usage during compile time. It's also obvious from the picture that this is > the single bottleneck of compilation speed (high I/O bytes, high memory > usage (the working set), ridiculous page fault counts).
> [image: Capture-cl.PNG]
> Countermeasures:
> - To handle mspdbsrv.exe issue, we need to separate the swap from > source so that the I/O and page fault pressure can be separated into two > different I/O channels (in my case, a different SATA port). This is solved > by adding a new disk to the system and make sure it's not used for swap. > (Control Panel->System and > Security->System->Advanced->Performance/Settings->Advanced->Virtual > memory/Change) > - Reduce the pressure of Windows Virtual Memory manager by reducing > concurrent jobs. In my case, 5 (number of physical cores - 1) is taken from > rules of thumb. It may not be optimal but works very well in my case.
> Actual results:
> Time required to build chrome.sln (DEBUG|Win32) reduced from 1:23:15 to > 49:30.
The killer for me is touch a file (just a .cc) and build chrome. Currently it takes around 4 minutes! Compare this to 40 seconds on my linux box... Both machines are the same (z600, two hard drives) but the windows side has Sophos and Bit9 to contend with.
How is the touch done? Invoking cygwin /usr/bin/touch? That will definitely take a while since it needs to pass cygwin process launch hack, loads all DLLs, run by Sophos scan, and Bits decryption. This command shall do it much faster
On Mon, Apr 11, 2011 at 3:01 PM, Scott Violet <s...@chromium.org> wrote: > On Mon, Apr 11, 2011 at 2:42 PM, Arthur Hsu <arthur...@chromium.org>wrote:
>> f you don't compile Chrome under Windows, feel free to ignore this e-mail.
>> Summary: use a separate disk to host Chrome source and reduce VC >> concurrent job count to (number of physical cores - 1) from default (number >> of logical cores) reduces compilation time on my machine from 1:23:15 to >> 49:30 (40.5% speed up)
>> Machine configuration: >> Dell Precision T3500, Xeon X5...@2.67 GHz, 12GB of RAM, initially 500GB >> SATA HD, BitLock disabled >> Windows 7 Enterprise >> Visual Studio 2008 SP1
>> Observations:
>> - By default, VC sets number of logical cores as max number of >> parallel project builds (Tools->Options->Project and Solutions->Build and >> Run). In my case, it's 12 (6 physical cores and hyper thread) >> - The "max number of parallel project builds" is actually number of >> VCBuildHelper.exe instances, not the number of concurrent cl.exe. Similar >> things happened in VC 2010: this number indicates number of MSBuild.exe >> instances, not cl.exe. See attached picture. >> - Also, each link.exe in the picture is committing high amount of >> memory (~1G each) and thus 12 instance will invite very high page fault >> counts. >> - mspdbsrv.exe is the service that synchronize and generate pdb >> usage during compile time. It's also obvious from the picture that this is >> the single bottleneck of compilation speed (high I/O bytes, high memory >> usage (the working set), ridiculous page fault counts).
>> [image: Capture-cl.PNG]
>> Countermeasures:
>> - To handle mspdbsrv.exe issue, we need to separate the swap from >> source so that the I/O and page fault pressure can be separated into two >> different I/O channels (in my case, a different SATA port). This is solved >> by adding a new disk to the system and make sure it's not used for swap. >> (Control Panel->System and >> Security->System->Advanced->Performance/Settings->Advanced->Virtual >> memory/Change) >> - Reduce the pressure of Windows Virtual Memory manager by reducing >> concurrent jobs. In my case, 5 (number of physical cores - 1) is taken from >> rules of thumb. It may not be optimal but works very well in my case.
>> Actual results:
>> Time required to build chrome.sln (DEBUG|Win32) reduced from 1:23:15 to >> 49:30.
> The killer for me is touch a file (just a .cc) and build chrome. Currently > it takes around 4 minutes! Compare this to 40 seconds on my linux box... > Both machines are the same (z600, two hard drives) but the windows side has > Sophos and Bit9 to contend with.
On Mon, Apr 11, 2011 at 3:20 PM, Arthur Hsu <arthur...@chromium.org> wrote: > How is the touch done? Invoking cygwin /usr/bin/touch? That will > definitely take a while since it needs to pass cygwin process launch hack, > loads all DLLs, run by Sophos scan, and Bits decryption. This command shall > do it much faster
> cmd /c "echo. 2>ph.txt"
> Replace the ph.txt with your file path.
> -Arthur
> On Mon, Apr 11, 2011 at 3:01 PM, Scott Violet <s...@chromium.org> wrote:
>> On Mon, Apr 11, 2011 at 2:42 PM, Arthur Hsu <arthur...@chromium.org>wrote:
>>> f you don't compile Chrome under Windows, feel free to ignore this >>> e-mail.
>>> Summary: use a separate disk to host Chrome source and reduce VC >>> concurrent job count to (number of physical cores - 1) from default (number >>> of logical cores) reduces compilation time on my machine from 1:23:15 to >>> 49:30 (40.5% speed up)
>>> Machine configuration: >>> Dell Precision T3500, Xeon X5...@2.67 GHz, 12GB of RAM, initially 500GB >>> SATA HD, BitLock disabled >>> Windows 7 Enterprise >>> Visual Studio 2008 SP1
>>> Observations:
>>> - By default, VC sets number of logical cores as max number of >>> parallel project builds (Tools->Options->Project and Solutions->Build and >>> Run). In my case, it's 12 (6 physical cores and hyper thread) >>> - The "max number of parallel project builds" is actually number of >>> VCBuildHelper.exe instances, not the number of concurrent cl.exe. Similar >>> things happened in VC 2010: this number indicates number of MSBuild.exe >>> instances, not cl.exe. See attached picture. >>> - Also, each link.exe in the picture is committing high amount of >>> memory (~1G each) and thus 12 instance will invite very high page fault >>> counts. >>> - mspdbsrv.exe is the service that synchronize and generate pdb >>> usage during compile time. It's also obvious from the picture that this is >>> the single bottleneck of compilation speed (high I/O bytes, high memory >>> usage (the working set), ridiculous page fault counts).
>>> [image: Capture-cl.PNG]
>>> Countermeasures:
>>> - To handle mspdbsrv.exe issue, we need to separate the swap from >>> source so that the I/O and page fault pressure can be separated into two >>> different I/O channels (in my case, a different SATA port). This is solved >>> by adding a new disk to the system and make sure it's not used for swap. >>> (Control Panel->System and >>> Security->System->Advanced->Performance/Settings->Advanced->Virtual >>> memory/Change) >>> - Reduce the pressure of Windows Virtual Memory manager by reducing >>> concurrent jobs. In my case, 5 (number of physical cores - 1) is taken from >>> rules of thumb. It may not be optimal but works very well in my case.
>>> Actual results:
>>> Time required to build chrome.sln (DEBUG|Win32) reduced from 1:23:15 to >>> 49:30.
>> The killer for me is touch a file (just a .cc) and build chrome. Currently >> it takes around 4 minutes! Compare this to 40 seconds on my linux box... >> Both machines are the same (z600, two hard drives) but the windows side has >> Sophos and Bit9 to contend with.
On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
> - The "max number of parallel project builds" is actually number of
> VCBuildHelper.exe instances, not the number of concurrent cl.exe. Similar
> things happened in VC 2010: this number indicates number of MSBuild.exe
> instances, not cl.exe. See attached picture.
The number of cl/link instances is controlled by the /MP switch and
set to use all your effective processors by default if you don't
specify a number - which is what chromium currently does; see
http://msdn.microsoft.com/en-us/library/bb385193.aspx. You can
override it by setting 'msvs_multi_core_compile': 0 and manually
setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' ->
'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe etc.
processes you want running per project.
For example, your include.gypi file could be this for limiting it to
12 processes per project:
-------------
{
'variables': {
'msvs_multi_core_compile': 0,
},
'target_defaults': {
'msvs_settings': {
'VCCLCompilerTool': {
'AdditionalOptions': ['/MP12'],
},
},
},
> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
> > - The "max number of parallel project builds" is actually number of
> > VCBuildHelper.exe instances, not the number of concurrent cl.exe. Similar
> > things happened in VC 2010: this number indicates number of MSBuild.exe
> > instances, not cl.exe. See attached picture.
> The number of cl/link instances is controlled by the /MP switch and
> set to use all your effective processors by default if you don't
> specify a number - which is what chromium currently does; seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You can
> override it by setting 'msvs_multi_core_compile': 0 and manually
> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' ->
> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe etc.
> processes you want running per project.
> For example, your include.gypi file could be this for limiting it to
> 12 processes per project:
> -------------
> {
> 'variables': {
> 'msvs_multi_core_compile': 0,
> },
> 'target_defaults': {
> 'msvs_settings': {
> 'VCCLCompilerTool': {
> 'AdditionalOptions': ['/MP12'],
> },
> },
> },}
I mainly use Linux dev environment because build time is faster than Windows.
As you know, link time on Windows is extremely slow!! So I always disabled pdb generation and no opt ref in Release mode manually.
I don't know why the Release setting still enable pdb generation as default though. Once disable them, mspdbsrv.exe consumes less memories and link time is shorten. Of course, it might help for debugger, but I don't use debugger these days.
On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> wrote: > I report 2.5 minutes with VS2010 for a single .cc touch and debug > build.
> BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" > edition.
> On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>> > - The "max number of parallel project builds" is actually number of >> > VCBuildHelper.exe instances, not the number of concurrent cl.exe. Similar >> > things happened in VC 2010: this number indicates number of MSBuild.exe >> > instances, not cl.exe. See attached picture.
>> The number of cl/link instances is controlled by the /MP switch and >> set to use all your effective processors by default if you don't >> specify a number - which is what chromium currently does; seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You can >> override it by setting 'msvs_multi_core_compile': 0 and manually >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' -> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe etc. >> processes you want running per project.
>> For example, your include.gypi file could be this for limiting it to >> 12 processes per project: >> ------------- >> { >> 'variables': { >> 'msvs_multi_core_compile': 0, >> }, >> 'target_defaults': { >> 'msvs_settings': { >> 'VCCLCompilerTool': { >> 'AdditionalOptions': ['/MP12'], >> }, >> }, >> },}
> I mainly use Linux dev environment because build time is faster than > Windows.
> As you know, link time on Windows is extremely slow!! > So I always disabled pdb generation and no opt ref in Release mode > manually.
> I don't know why the Release setting still enable pdb generation as > default though. > Once disable them, mspdbsrv.exe consumes less memories and link time is > shorten. > Of course, it might help for debugger, but I don't use debugger these days.
> Thanks,
> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> wrote: > > I report 2.5 minutes with VS2010 for a single .cc touch and debug > > build.
> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" > > edition.
> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: > >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
> >> > - The "max number of parallel project builds" is actually number of > >> > VCBuildHelper.exe instances, not the number of concurrent cl.exe. > Similar > >> > things happened in VC 2010: this number indicates number of > MSBuild.exe > >> > instances, not cl.exe. See attached picture.
> >> The number of cl/link instances is controlled by the /MP switch and > >> set to use all your effective processors by default if you don't > >> specify a number - which is what chromium currently does; seehttp:// > msdn.microsoft.com/en-us/library/bb385193.aspx. You can > >> override it by setting 'msvs_multi_core_compile': 0 and manually > >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' -> > >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe etc. > >> processes you want running per project.
> >> For example, your include.gypi file could be this for limiting it to > >> 12 processes per project: > >> ------------- > >> { > >> 'variables': { > >> 'msvs_multi_core_compile': 0, > >> }, > >> 'target_defaults': { > >> 'msvs_settings': { > >> 'VCCLCompilerTool': { > >> 'AdditionalOptions': ['/MP12'], > >> }, > >> }, > >> },}
sanje...@chromium.org> wrote: > PDB generation is needed for making crash reports have readable stack > traces (and for debugging, of course).
> On Wed, Apr 13, 2011 at 12:22 PM, Naoki Takano <takano.na...@gmail.com>wrote:
>> Hi,
>> I mainly use Linux dev environment because build time is faster than >> Windows.
>> As you know, link time on Windows is extremely slow!! >> So I always disabled pdb generation and no opt ref in Release mode >> manually.
>> I don't know why the Release setting still enable pdb generation as >> default though. >> Once disable them, mspdbsrv.exe consumes less memories and link time is >> shorten. >> Of course, it might help for debugger, but I don't use debugger these >> days.
>> Thanks,
>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> wrote: >> > I report 2.5 minutes with VS2010 for a single .cc touch and debug >> > build.
>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" >> > edition.
>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>> >> > - The "max number of parallel project builds" is actually number >> of >> >> > VCBuildHelper.exe instances, not the number of concurrent cl.exe. >> Similar >> >> > things happened in VC 2010: this number indicates number of >> MSBuild.exe >> >> > instances, not cl.exe. See attached picture.
>> >> The number of cl/link instances is controlled by the /MP switch and >> >> set to use all your effective processors by default if you don't >> >> specify a number - which is what chromium currently does; seehttp:// >> msdn.microsoft.com/en-us/library/bb385193.aspx. You can >> >> override it by setting 'msvs_multi_core_compile': 0 and manually >> >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' -> >> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe etc. >> >> processes you want running per project.
>> >> For example, your include.gypi file could be this for limiting it to >> >> 12 processes per project: >> >> ------------- >> >> { >> >> 'variables': { >> >> 'msvs_multi_core_compile': 0, >> >> }, >> >> 'target_defaults': { >> >> 'msvs_settings': { >> >> 'VCCLCompilerTool': { >> >> 'AdditionalOptions': ['/MP12'], >> >> }, >> >> }, >> >> },}
<vand...@chromium.org> wrote: > Should we have a Release-NoSymbol target for faster development builds? > -- > Steve
> On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan > <sanje...@chromium.org> wrote:
>> PDB generation is needed for making crash reports have readable stack >> traces (and for debugging, of course).
>> On Wed, Apr 13, 2011 at 12:22 PM, Naoki Takano <takano.na...@gmail.com> >> wrote:
>>> Hi,
>>> I mainly use Linux dev environment because build time is faster than >>> Windows.
>>> As you know, link time on Windows is extremely slow!! >>> So I always disabled pdb generation and no opt ref in Release mode >>> manually.
>>> I don't know why the Release setting still enable pdb generation as >>> default though. >>> Once disable them, mspdbsrv.exe consumes less memories and link time is >>> shorten. >>> Of course, it might help for debugger, but I don't use debugger these >>> days.
>>> Thanks,
>>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> wrote: >>> > I report 2.5 minutes with VS2010 for a single .cc touch and debug >>> > build.
>>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" >>> > edition.
>>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>>> >> > - The "max number of parallel project builds" is actually number >>> >> > of >>> >> > VCBuildHelper.exe instances, not the number of concurrent cl.exe. >>> >> > Similar >>> >> > things happened in VC 2010: this number indicates number of >>> >> > MSBuild.exe >>> >> > instances, not cl.exe. See attached picture.
>>> >> The number of cl/link instances is controlled by the /MP switch and >>> >> set to use all your effective processors by default if you don't >>> >> specify a number - which is what chromium currently does; >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You can >>> >> override it by setting 'msvs_multi_core_compile': 0 and manually >>> >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' -> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe etc. >>> >> processes you want running per project.
>>> >> For example, your include.gypi file could be this for limiting it to >>> >> 12 processes per project: >>> >> ------------- >>> >> { >>> >> 'variables': { >>> >> 'msvs_multi_core_compile': 0, >>> >> }, >>> >> 'target_defaults': { >>> >> 'msvs_settings': { >>> >> 'VCCLCompilerTool': { >>> >> 'AdditionalOptions': ['/MP12'], >>> >> }, >>> >> }, >>> >> },}
I've been using the Multi-DLL build and used a tool to boost my system file cache to 2GB. If I touch a file in WebKit (GraphicsContext3DChromium.cpp) and build the Chrome target in Debug from VS 2008 it takes 10 seconds or less to complete. This is with a hot cache (I've built several times recently).
Brian
On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com>wrote:
> But I agree with Steve. Of course, we can change manually setting, but > it's convenient if we have.
> Thanks,
> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart > <vand...@chromium.org> wrote: > > Should we have a Release-NoSymbol target for faster development builds? > > -- > > Steve
> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan > > <sanje...@chromium.org> wrote:
> >> PDB generation is needed for making crash reports have readable stack > >> traces (and for debugging, of course).
> >> On Wed, Apr 13, 2011 at 12:22 PM, Naoki Takano <takano.na...@gmail.com> > >> wrote:
> >>> Hi,
> >>> I mainly use Linux dev environment because build time is faster than > >>> Windows.
> >>> As you know, link time on Windows is extremely slow!! > >>> So I always disabled pdb generation and no opt ref in Release mode > >>> manually.
> >>> I don't know why the Release setting still enable pdb generation as > >>> default though. > >>> Once disable them, mspdbsrv.exe consumes less memories and link time is > >>> shorten. > >>> Of course, it might help for debugger, but I don't use debugger these > >>> days.
> >>> Thanks,
> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> > wrote: > >>> > I report 2.5 minutes with VS2010 for a single .cc touch and debug > >>> > build.
> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" > >>> > edition.
> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: > >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
> >>> >> > - The "max number of parallel project builds" is actually > number > >>> >> > of > >>> >> > VCBuildHelper.exe instances, not the number of concurrent > cl.exe. > >>> >> > Similar > >>> >> > things happened in VC 2010: this number indicates number of > >>> >> > MSBuild.exe > >>> >> > instances, not cl.exe. See attached picture.
> >>> >> The number of cl/link instances is controlled by the /MP switch and > >>> >> set to use all your effective processors by default if you don't > >>> >> specify a number - which is what chromium currently does; > >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You can > >>> >> override it by setting 'msvs_multi_core_compile': 0 and manually > >>> >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' -> > >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe > etc. > >>> >> processes you want running per project.
> >>> >> For example, your include.gypi file could be this for limiting it to > >>> >> 12 processes per project: > >>> >> ------------- > >>> >> { > >>> >> 'variables': { > >>> >> 'msvs_multi_core_compile': 0, > >>> >> }, > >>> >> 'target_defaults': { > >>> >> 'msvs_settings': { > >>> >> 'VCCLCompilerTool': { > >>> >> 'AdditionalOptions': ['/MP12'], > >>> >> }, > >>> >> }, > >>> >> },}
On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> wrote: > I've been using the Multi-DLL build and used a tool to boost my system file > cache to 2GB. If I touch a file in WebKit (GraphicsContext3DChromium.cpp) > and build the Chrome target in Debug from VS 2008 it takes 10 seconds or > less to complete. This is with a hot cache (I've built several times > recently).
> Brian
> On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com>wrote:
>> Of course, I know PDB generation purpose.
>> But I agree with Steve. Of course, we can change manually setting, but >> it's convenient if we have.
>> Thanks,
>> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >> <vand...@chromium.org> wrote: >> > Should we have a Release-NoSymbol target for faster development builds? >> > -- >> > Steve
>> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >> > <sanje...@chromium.org> wrote:
>> >> PDB generation is needed for making crash reports have readable stack >> >> traces (and for debugging, of course).
>> >> On Wed, Apr 13, 2011 at 12:22 PM, Naoki Takano <takano.na...@gmail.com
>> >> wrote:
>> >>> Hi,
>> >>> I mainly use Linux dev environment because build time is faster than >> >>> Windows.
>> >>> As you know, link time on Windows is extremely slow!! >> >>> So I always disabled pdb generation and no opt ref in Release mode >> >>> manually.
>> >>> I don't know why the Release setting still enable pdb generation as >> >>> default though. >> >>> Once disable them, mspdbsrv.exe consumes less memories and link time >> is >> >>> shorten. >> >>> Of course, it might help for debugger, but I don't use debugger these >> >>> days.
>> >>> Thanks,
>> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >> wrote: >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and debug >> >>> > build.
>> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" >> >>> > edition.
>> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>> >>> >> > - The "max number of parallel project builds" is actually >> number >> >>> >> > of >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >> cl.exe. >> >>> >> > Similar >> >>> >> > things happened in VC 2010: this number indicates number of >> >>> >> > MSBuild.exe >> >>> >> > instances, not cl.exe. See attached picture.
>> >>> >> The number of cl/link instances is controlled by the /MP switch and >> >>> >> set to use all your effective processors by default if you don't >> >>> >> specify a number - which is what chromium currently does; >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You can >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and manually >> >>> >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' >> -> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe >> etc. >> >>> >> processes you want running per project.
>> >>> >> For example, your include.gypi file could be this for limiting it >> to >> >>> >> 12 processes per project: >> >>> >> ------------- >> >>> >> { >> >>> >> 'variables': { >> >>> >> 'msvs_multi_core_compile': 0, >> >>> >> }, >> >>> >> 'target_defaults': { >> >>> >> 'msvs_settings': { >> >>> >> 'VCCLCompilerTool': { >> >>> >> 'AdditionalOptions': ['/MP12'], >> >>> >> }, >> >>> >> }, >> >>> >> },}
On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> wrote: > I've been using the Multi-DLL build and used a tool to boost my system file > cache to 2GB. If I touch a file in WebKit (GraphicsContext3DChromium.cpp) > and build the Chrome target in Debug from VS 2008 it takes 10 seconds or > less to complete. This is with a hot cache (I've built several times > recently). > Brian
> On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> > wrote:
>> Of course, I know PDB generation purpose.
>> But I agree with Steve. Of course, we can change manually setting, but >> it's convenient if we have.
>> Thanks,
>> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >> <vand...@chromium.org> wrote: >> > Should we have a Release-NoSymbol target for faster development builds? >> > -- >> > Steve
>> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >> > <sanje...@chromium.org> wrote:
>> >> PDB generation is needed for making crash reports have readable stack >> >> traces (and for debugging, of course).
>> >> On Wed, Apr 13, 2011 at 12:22 PM, Naoki Takano <takano.na...@gmail.com> >> >> wrote:
>> >>> Hi,
>> >>> I mainly use Linux dev environment because build time is faster than >> >>> Windows.
>> >>> As you know, link time on Windows is extremely slow!! >> >>> So I always disabled pdb generation and no opt ref in Release mode >> >>> manually.
>> >>> I don't know why the Release setting still enable pdb generation as >> >>> default though. >> >>> Once disable them, mspdbsrv.exe consumes less memories and link time >> >>> is >> >>> shorten. >> >>> Of course, it might help for debugger, but I don't use debugger these >> >>> days.
>> >>> Thanks,
>> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >> >>> wrote: >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and debug >> >>> > build.
>> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" >> >>> > edition.
>> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>> >>> >> > - The "max number of parallel project builds" is actually >> >>> >> > number >> >>> >> > of >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >> >>> >> > cl.exe. >> >>> >> > Similar >> >>> >> > things happened in VC 2010: this number indicates number of >> >>> >> > MSBuild.exe >> >>> >> > instances, not cl.exe. See attached picture.
>> >>> >> The number of cl/link instances is controlled by the /MP switch and >> >>> >> set to use all your effective processors by default if you don't >> >>> >> specify a number - which is what chromium currently does; >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You can >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and manually >> >>> >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' >> >>> >> -> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe >> >>> >> etc. >> >>> >> processes you want running per project.
>> >>> >> For example, your include.gypi file could be this for limiting it >> >>> >> to >> >>> >> 12 processes per project: >> >>> >> ------------- >> >>> >> { >> >>> >> 'variables': { >> >>> >> 'msvs_multi_core_compile': 0, >> >>> >> }, >> >>> >> 'target_defaults': { >> >>> >> 'msvs_settings': { >> >>> >> 'VCCLCompilerTool': { >> >>> >> 'AdditionalOptions': ['/MP12'], >> >>> >> }, >> >>> >> }, >> >>> >> },}
To enable the Multi-DLL build I put: {'variables': {'component': 'shared_library'}} in c:\users\<my username>\.gyp\include.gypi I had to blow-away my <chrome>\src\build\Debug and <chrome>\src\build\Release dirs before the first builds after switching to Multi-DLL.
I also have my chrome tree on a different drive than my OS.
On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote: > SWEETNESS! > Please share with the rest of us how to set this up.
> -Scott
> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> > wrote: > > I've been using the Multi-DLL build and used a tool to boost my system > file > > cache to 2GB. If I touch a file in WebKit (GraphicsContext3DChromium.cpp) > > and build the Chrome target in Debug from VS 2008 it takes 10 seconds or > > less to complete. This is with a hot cache (I've built several times > > recently). > > Brian
> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> > > wrote:
> >> Of course, I know PDB generation purpose.
> >> But I agree with Steve. Of course, we can change manually setting, but > >> it's convenient if we have.
> >> Thanks,
> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart > >> <vand...@chromium.org> wrote: > >> > Should we have a Release-NoSymbol target for faster development > builds? > >> > -- > >> > Steve
> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan > >> > <sanje...@chromium.org> wrote:
> >> >> PDB generation is needed for making crash reports have readable stack > >> >> traces (and for debugging, of course).
> >> >> On Wed, Apr 13, 2011 at 12:22 PM, Naoki Takano < > takano.na...@gmail.com> > >> >> wrote:
> >> >>> Hi,
> >> >>> I mainly use Linux dev environment because build time is faster than > >> >>> Windows.
> >> >>> As you know, link time on Windows is extremely slow!! > >> >>> So I always disabled pdb generation and no opt ref in Release mode > >> >>> manually.
> >> >>> I don't know why the Release setting still enable pdb generation as > >> >>> default though. > >> >>> Once disable them, mspdbsrv.exe consumes less memories and link time > >> >>> is > >> >>> shorten. > >> >>> Of course, it might help for debugger, but I don't use debugger > these > >> >>> days.
> >> >>> Thanks,
> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> > >> >>> wrote: > >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and debug > >> >>> > build.
> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" > >> >>> > edition.
> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: > >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
> >> >>> >> > - The "max number of parallel project builds" is actually > >> >>> >> > number > >> >>> >> > of > >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent > >> >>> >> > cl.exe. > >> >>> >> > Similar > >> >>> >> > things happened in VC 2010: this number indicates number of > >> >>> >> > MSBuild.exe > >> >>> >> > instances, not cl.exe. See attached picture.
> >> >>> >> The number of cl/link instances is controlled by the /MP switch > and > >> >>> >> set to use all your effective processors by default if you don't > >> >>> >> specify a number - which is what chromium currently does; > >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You > can > >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and manually > >> >>> >> setting it yourself through 'msvs_settings' -> 'VCCLCompilerTool' > >> >>> >> -> > >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of cl.exe > >> >>> >> etc. > >> >>> >> processes you want running per project.
> >> >>> >> For example, your include.gypi file could be this for limiting it > >> >>> >> to > >> >>> >> 12 processes per project: > >> >>> >> ------------- > >> >>> >> { > >> >>> >> 'variables': { > >> >>> >> 'msvs_multi_core_compile': 0, > >> >>> >> }, > >> >>> >> 'target_defaults': { > >> >>> >> 'msvs_settings': { > >> >>> >> 'VCCLCompilerTool': { > >> >>> >> 'AdditionalOptions': ['/MP12'], > >> >>> >> }, > >> >>> >> }, > >> >>> >> },}
On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> wrote: > Sure, this is all I did: > To boost the file cache I used this tool: > http://www.analogx.com/contents/download/System/cb/Freeware.htm > The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. > To enable the Multi-DLL build I put: > {'variables': {'component': 'shared_library'}} > in c:\users\<my username>\.gyp\include.gypi > I had to blow-away my <chrome>\src\build\Debug > and <chrome>\src\build\Release dirs before the first builds after switching > to Multi-DLL. > I also have my chrome tree on a different drive than my OS. > Brian
> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote:
>> SWEETNESS! >> Please share with the rest of us how to set this up.
>> -Scott
>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> >> wrote: >> > I've been using the Multi-DLL build and used a tool to boost my system >> > file >> > cache to 2GB. If I touch a file in WebKit >> > (GraphicsContext3DChromium.cpp) >> > and build the Chrome target in Debug from VS 2008 it takes 10 seconds or >> > less to complete. This is with a hot cache (I've built several times >> > recently). >> > Brian
>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> >> > wrote:
>> >> Of course, I know PDB generation purpose.
>> >> But I agree with Steve. Of course, we can change manually setting, but >> >> it's convenient if we have.
>> >> Thanks,
>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >> >> <vand...@chromium.org> wrote: >> >> > Should we have a Release-NoSymbol target for faster development >> >> > builds? >> >> > -- >> >> > Steve
>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >> >> > <sanje...@chromium.org> wrote:
>> >> >> PDB generation is needed for making crash reports have readable >> >> >> stack >> >> >> traces (and for debugging, of course).
>> >> >>> I mainly use Linux dev environment because build time is faster >> >> >>> than >> >> >>> Windows.
>> >> >>> As you know, link time on Windows is extremely slow!! >> >> >>> So I always disabled pdb generation and no opt ref in Release mode >> >> >>> manually.
>> >> >>> I don't know why the Release setting still enable pdb generation as >> >> >>> default though. >> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link >> >> >>> time >> >> >>> is >> >> >>> shorten. >> >> >>> Of course, it might help for debugger, but I don't use debugger >> >> >>> these >> >> >>> days.
>> >> >>> Thanks,
>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >> >> >>> wrote: >> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and debug >> >> >>> > build.
>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" >> >> >>> > edition.
>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>> >> >>> >> > - The "max number of parallel project builds" is actually >> >> >>> >> > number >> >> >>> >> > of >> >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >> >> >>> >> > cl.exe. >> >> >>> >> > Similar >> >> >>> >> > things happened in VC 2010: this number indicates number of >> >> >>> >> > MSBuild.exe >> >> >>> >> > instances, not cl.exe. See attached picture.
>> >> >>> >> The number of cl/link instances is controlled by the /MP switch >> >> >>> >> and >> >> >>> >> set to use all your effective processors by default if you don't >> >> >>> >> specify a number - which is what chromium currently does; >> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You >> >> >>> >> can >> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and manually >> >> >>> >> setting it yourself through 'msvs_settings' -> >> >> >>> >> 'VCCLCompilerTool' >> >> >>> >> -> >> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of >> >> >>> >> cl.exe >> >> >>> >> etc. >> >> >>> >> processes you want running per project.
>> >> >>> >> For example, your include.gypi file could be this for limiting >> >> >>> >> it >> >> >>> >> to >> >> >>> >> 12 processes per project: >> >> >>> >> ------------- >> >> >>> >> { >> >> >>> >> 'variables': { >> >> >>> >> 'msvs_multi_core_compile': 0, >> >> >>> >> }, >> >> >>> >> 'target_defaults': { >> >> >>> >> 'msvs_settings': { >> >> >>> >> 'VCCLCompilerTool': { >> >> >>> >> 'AdditionalOptions': ['/MP12'], >> >> >>> >> }, >> >> >>> >> }, >> >> >>> >> },}
Just wanted to mention that switching to the multi-dll build in this past couple of weeks has been a tremendous productivity boost. Not only the code builds faster (the webkit library links in under 10 secs) but also now the VS debugger seems to be able to load and run chrome within seconds. If windows is your primary development platform, do yourself a favor and give it a try!
Many kudos to Brian for bringing it up.
Vangelis PS I also used the utility that Brian mentions to set the file cache size to 2GB. I don't know how much that plays into the speed improvement.
> To enable the Multi-DLL build I put: > {'variables': {'component': 'shared_library'}} > in c:\users\<my username>\.gyp\include.gypi > I had to blow-away my <chrome>\src\build\Debug > and <chrome>\src\build\Release dirs before the first builds after switching > to Multi-DLL.
> I also have my chrome tree on a different drive than my OS.
> Brian
> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote:
>> SWEETNESS! >> Please share with the rest of us how to set this up.
>> -Scott
>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> >> wrote: >> > I've been using the Multi-DLL build and used a tool to boost my system >> file >> > cache to 2GB. If I touch a file in WebKit >> (GraphicsContext3DChromium.cpp) >> > and build the Chrome target in Debug from VS 2008 it takes 10 seconds or >> > less to complete. This is with a hot cache (I've built several times >> > recently). >> > Brian
>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> >> > wrote:
>> >> Of course, I know PDB generation purpose.
>> >> But I agree with Steve. Of course, we can change manually setting, but >> >> it's convenient if we have.
>> >> Thanks,
>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >> >> <vand...@chromium.org> wrote: >> >> > Should we have a Release-NoSymbol target for faster development >> builds? >> >> > -- >> >> > Steve
>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >> >> > <sanje...@chromium.org> wrote:
>> >> >> PDB generation is needed for making crash reports have readable >> stack >> >> >> traces (and for debugging, of course).
>> >> >> On Wed, Apr 13, 2011 at 12:22 PM, Naoki Takano < >> takano.na...@gmail.com> >> >> >> wrote:
>> >> >>> Hi,
>> >> >>> I mainly use Linux dev environment because build time is faster >> than >> >> >>> Windows.
>> >> >>> As you know, link time on Windows is extremely slow!! >> >> >>> So I always disabled pdb generation and no opt ref in Release mode >> >> >>> manually.
>> >> >>> I don't know why the Release setting still enable pdb generation as >> >> >>> default though. >> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link >> time >> >> >>> is >> >> >>> shorten. >> >> >>> Of course, it might help for debugger, but I don't use debugger >> these >> >> >>> days.
>> >> >>> Thanks,
>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >> >> >>> wrote: >> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and debug >> >> >>> > build.
>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the "ultimate" >> >> >>> > edition.
>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>> >> >>> >> > - The "max number of parallel project builds" is actually >> >> >>> >> > number >> >> >>> >> > of >> >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >> >> >>> >> > cl.exe. >> >> >>> >> > Similar >> >> >>> >> > things happened in VC 2010: this number indicates number of >> >> >>> >> > MSBuild.exe >> >> >>> >> > instances, not cl.exe. See attached picture.
>> >> >>> >> The number of cl/link instances is controlled by the /MP switch >> and >> >> >>> >> set to use all your effective processors by default if you don't >> >> >>> >> specify a number - which is what chromium currently does; >> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You >> can >> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and manually >> >> >>> >> setting it yourself through 'msvs_settings' -> >> 'VCCLCompilerTool' >> >> >>> >> -> >> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of >> cl.exe >> >> >>> >> etc. >> >> >>> >> processes you want running per project.
>> >> >>> >> For example, your include.gypi file could be this for limiting >> it >> >> >>> >> to >> >> >>> >> 12 processes per project: >> >> >>> >> ------------- >> >> >>> >> { >> >> >>> >> 'variables': { >> >> >>> >> 'msvs_multi_core_compile': 0, >> >> >>> >> }, >> >> >>> >> 'target_defaults': { >> >> >>> >> 'msvs_settings': { >> >> >>> >> 'VCCLCompilerTool': { >> >> >>> >> 'AdditionalOptions': ['/MP12'], >> >> >>> >> }, >> >> >>> >> }, >> >> >>> >> },}
On Tue, Apr 19, 2011 at 4:14 PM, Vangelis Kokkevis <vange...@google.com> wrote: > Just wanted to mention that switching to the multi-dll build in this past > couple of weeks has been a tremendous productivity boost. Not only the code > builds faster (the webkit library links in under 10 secs) but also now the > VS debugger seems to be able to load and run chrome within seconds. If > windows is your primary development platform, do yourself a favor and give > it a try! > Many kudos to Brian for bringing it up. > Vangelis > PS I also used the utility that Brian mentions to set the file cache size to > 2GB. I don't know how much that plays into the speed improvement.
> On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> wrote:
>> Sure, this is all I did: >> To boost the file cache I used this tool: >> http://www.analogx.com/contents/download/System/cb/Freeware.htm >> The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. >> To enable the Multi-DLL build I put: >> {'variables': {'component': 'shared_library'}} >> in c:\users\<my username>\.gyp\include.gypi >> I had to blow-away my <chrome>\src\build\Debug >> and <chrome>\src\build\Release dirs before the first builds after switching >> to Multi-DLL. >> I also have my chrome tree on a different drive than my OS. >> Brian
>> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote:
>>> SWEETNESS! >>> Please share with the rest of us how to set this up.
>>> -Scott
>>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> >>> wrote: >>> > I've been using the Multi-DLL build and used a tool to boost my system >>> > file >>> > cache to 2GB. If I touch a file in WebKit >>> > (GraphicsContext3DChromium.cpp) >>> > and build the Chrome target in Debug from VS 2008 it takes 10 seconds >>> > or >>> > less to complete. This is with a hot cache (I've built several times >>> > recently). >>> > Brian
>>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> >>> > wrote:
>>> >> Of course, I know PDB generation purpose.
>>> >> But I agree with Steve. Of course, we can change manually setting, but >>> >> it's convenient if we have.
>>> >> Thanks,
>>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >>> >> <vand...@chromium.org> wrote: >>> >> > Should we have a Release-NoSymbol target for faster development >>> >> > builds? >>> >> > -- >>> >> > Steve
>>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >>> >> > <sanje...@chromium.org> wrote:
>>> >> >> PDB generation is needed for making crash reports have readable >>> >> >> stack >>> >> >> traces (and for debugging, of course).
>>> >> >>> I mainly use Linux dev environment because build time is faster >>> >> >>> than >>> >> >>> Windows.
>>> >> >>> As you know, link time on Windows is extremely slow!! >>> >> >>> So I always disabled pdb generation and no opt ref in Release mode >>> >> >>> manually.
>>> >> >>> I don't know why the Release setting still enable pdb generation >>> >> >>> as >>> >> >>> default though. >>> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link >>> >> >>> time >>> >> >>> is >>> >> >>> shorten. >>> >> >>> Of course, it might help for debugger, but I don't use debugger >>> >> >>> these >>> >> >>> days.
>>> >> >>> Thanks,
>>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >>> >> >>> wrote: >>> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and >>> >> >>> > debug >>> >> >>> > build.
>>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the >>> >> >>> > "ultimate" >>> >> >>> > edition.
>>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >>> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>>> >> >>> >> > - The "max number of parallel project builds" is actually >>> >> >>> >> > number >>> >> >>> >> > of >>> >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >>> >> >>> >> > cl.exe. >>> >> >>> >> > Similar >>> >> >>> >> > things happened in VC 2010: this number indicates number >>> >> >>> >> > of >>> >> >>> >> > MSBuild.exe >>> >> >>> >> > instances, not cl.exe. See attached picture.
>>> >> >>> >> The number of cl/link instances is controlled by the /MP switch >>> >> >>> >> and >>> >> >>> >> set to use all your effective processors by default if you >>> >> >>> >> don't >>> >> >>> >> specify a number - which is what chromium currently does; >>> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You >>> >> >>> >> can >>> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and >>> >> >>> >> manually >>> >> >>> >> setting it yourself through 'msvs_settings' -> >>> >> >>> >> 'VCCLCompilerTool' >>> >> >>> >> -> >>> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of >>> >> >>> >> cl.exe >>> >> >>> >> etc. >>> >> >>> >> processes you want running per project.
>>> >> >>> >> For example, your include.gypi file could be this for limiting >>> >> >>> >> it >>> >> >>> >> to >>> >> >>> >> 12 processes per project: >>> >> >>> >> ------------- >>> >> >>> >> { >>> >> >>> >> 'variables': { >>> >> >>> >> 'msvs_multi_core_compile': 0, >>> >> >>> >> }, >>> >> >>> >> 'target_defaults': { >>> >> >>> >> 'msvs_settings': { >>> >> >>> >> 'VCCLCompilerTool': { >>> >> >>> >> 'AdditionalOptions': ['/MP12'], >>> >> >>> >> }, >>> >> >>> >> }, >>> >> >>> >> },}
On Tue, Apr 19, 2011 at 1:19 PM, Mike Reed <r...@google.com> wrote: > What bot will exercise this? i.e. gcl try foo --bot=?
> On Tue, Apr 19, 2011 at 4:14 PM, Vangelis Kokkevis <vange...@google.com> wrote: >> Just wanted to mention that switching to the multi-dll build in this past >> couple of weeks has been a tremendous productivity boost. Not only the code >> builds faster (the webkit library links in under 10 secs) but also now the >> VS debugger seems to be able to load and run chrome within seconds. If >> windows is your primary development platform, do yourself a favor and give >> it a try! >> Many kudos to Brian for bringing it up. >> Vangelis >> PS I also used the utility that Brian mentions to set the file cache size to >> 2GB. I don't know how much that plays into the speed improvement.
>> On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> wrote:
>>> Sure, this is all I did: >>> To boost the file cache I used this tool: >>> http://www.analogx.com/contents/download/System/cb/Freeware.htm >>> The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. >>> To enable the Multi-DLL build I put: >>> {'variables': {'component': 'shared_library'}} >>> in c:\users\<my username>\.gyp\include.gypi >>> I had to blow-away my <chrome>\src\build\Debug >>> and <chrome>\src\build\Release dirs before the first builds after switching >>> to Multi-DLL. >>> I also have my chrome tree on a different drive than my OS. >>> Brian
>>> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote:
>>>> SWEETNESS! >>>> Please share with the rest of us how to set this up.
>>>> -Scott
>>>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> >>>> wrote: >>>> > I've been using the Multi-DLL build and used a tool to boost my system >>>> > file >>>> > cache to 2GB. If I touch a file in WebKit >>>> > (GraphicsContext3DChromium.cpp) >>>> > and build the Chrome target in Debug from VS 2008 it takes 10 seconds >>>> > or >>>> > less to complete. This is with a hot cache (I've built several times >>>> > recently). >>>> > Brian
>>>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> >>>> > wrote:
>>>> >> Of course, I know PDB generation purpose.
>>>> >> But I agree with Steve. Of course, we can change manually setting, but >>>> >> it's convenient if we have.
>>>> >> Thanks,
>>>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >>>> >> <vand...@chromium.org> wrote: >>>> >> > Should we have a Release-NoSymbol target for faster development >>>> >> > builds? >>>> >> > -- >>>> >> > Steve
>>>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >>>> >> > <sanje...@chromium.org> wrote:
>>>> >> >> PDB generation is needed for making crash reports have readable >>>> >> >> stack >>>> >> >> traces (and for debugging, of course).
>>>> >> >>> I mainly use Linux dev environment because build time is faster >>>> >> >>> than >>>> >> >>> Windows.
>>>> >> >>> As you know, link time on Windows is extremely slow!! >>>> >> >>> So I always disabled pdb generation and no opt ref in Release mode >>>> >> >>> manually.
>>>> >> >>> I don't know why the Release setting still enable pdb generation >>>> >> >>> as >>>> >> >>> default though. >>>> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link >>>> >> >>> time >>>> >> >>> is >>>> >> >>> shorten. >>>> >> >>> Of course, it might help for debugger, but I don't use debugger >>>> >> >>> these >>>> >> >>> days.
>>>> >> >>> Thanks,
>>>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >>>> >> >>> wrote: >>>> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and >>>> >> >>> > debug >>>> >> >>> > build.
>>>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the >>>> >> >>> > "ultimate" >>>> >> >>> > edition.
>>>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >>>> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>>>> >> >>> >> > - The "max number of parallel project builds" is actually >>>> >> >>> >> > number >>>> >> >>> >> > of >>>> >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >>>> >> >>> >> > cl.exe. >>>> >> >>> >> > Similar >>>> >> >>> >> > things happened in VC 2010: this number indicates number >>>> >> >>> >> > of >>>> >> >>> >> > MSBuild.exe >>>> >> >>> >> > instances, not cl.exe. See attached picture.
>>>> >> >>> >> The number of cl/link instances is controlled by the /MP switch >>>> >> >>> >> and >>>> >> >>> >> set to use all your effective processors by default if you >>>> >> >>> >> don't >>>> >> >>> >> specify a number - which is what chromium currently does; >>>> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You >>>> >> >>> >> can >>>> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and >>>> >> >>> >> manually >>>> >> >>> >> setting it yourself through 'msvs_settings' -> >>>> >> >>> >> 'VCCLCompilerTool' >>>> >> >>> >> -> >>>> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of >>>> >> >>> >> cl.exe >>>> >> >>> >> etc. >>>> >> >>> >> processes you want running per project.
>>>> >> >>> >> For example, your include.gypi file could be this for limiting >>>> >> >>> >> it >>>> >> >>> >> to >>>> >> >>> >> 12 processes per project: >>>> >> >>> >> ------------- >>>> >> >>> >> { >>>> >> >>> >> 'variables': { >>>> >> >>> >> 'msvs_multi_core_compile': 0, >>>> >> >>> >> }, >>>> >> >>> >> 'target_defaults': { >>>> >> >>> >> 'msvs_settings': { >>>> >> >>> >> 'VCCLCompilerTool': { >>>> >> >>> >> 'AdditionalOptions': ['/MP12'], >>>> >> >>> >> }, >>>> >> >>> >> }, >>>> >> >>> >> },}
On Tue, Apr 19, 2011 at 1:21 PM, Lei Zhang <thes...@chromium.org> wrote: > I don't think we have shared configuration try bots for either Windows or > Linux.
> On Tue, Apr 19, 2011 at 1:19 PM, Mike Reed <r...@google.com> wrote: > > What bot will exercise this? i.e. gcl try foo --bot=?
> > On Tue, Apr 19, 2011 at 4:14 PM, Vangelis Kokkevis <vange...@google.com> > wrote: > >> Just wanted to mention that switching to the multi-dll build in this > past > >> couple of weeks has been a tremendous productivity boost. Not only the > code > >> builds faster (the webkit library links in under 10 secs) but also now > the > >> VS debugger seems to be able to load and run chrome within seconds. If > >> windows is your primary development platform, do yourself a favor and > give > >> it a try! > >> Many kudos to Brian for bringing it up. > >> Vangelis > >> PS I also used the utility that Brian mentions to set the file cache > size to > >> 2GB. I don't know how much that plays into the speed improvement.
> >> On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> > wrote:
> >>> Sure, this is all I did: > >>> To boost the file cache I used this tool: > >>> http://www.analogx.com/contents/download/System/cb/Freeware.htm > >>> The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. > >>> To enable the Multi-DLL build I put: > >>> {'variables': {'component': 'shared_library'}} > >>> in c:\users\<my username>\.gyp\include.gypi > >>> I had to blow-away my <chrome>\src\build\Debug > >>> and <chrome>\src\build\Release dirs before the first builds after > switching > >>> to Multi-DLL. > >>> I also have my chrome tree on a different drive than my OS. > >>> Brian
> >>> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> > wrote:
> >>>> SWEETNESS! > >>>> Please share with the rest of us how to set this up.
> >>>> -Scott
> >>>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> > >>>> wrote: > >>>> > I've been using the Multi-DLL build and used a tool to boost my > system > >>>> > file > >>>> > cache to 2GB. If I touch a file in WebKit > >>>> > (GraphicsContext3DChromium.cpp) > >>>> > and build the Chrome target in Debug from VS 2008 it takes 10 > seconds > >>>> > or > >>>> > less to complete. This is with a hot cache (I've built several times > >>>> > recently). > >>>> > Brian
> >>>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano < > takano.na...@gmail.com> > >>>> > wrote:
> >>>> >> Of course, I know PDB generation purpose.
> >>>> >> But I agree with Steve. Of course, we can change manually setting, > but > >>>> >> it's convenient if we have.
> >>>> >> Thanks,
> >>>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart > >>>> >> <vand...@chromium.org> wrote: > >>>> >> > Should we have a Release-NoSymbol target for faster development > >>>> >> > builds? > >>>> >> > -- > >>>> >> > Steve
> >>>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan > >>>> >> > <sanje...@chromium.org> wrote:
> >>>> >> >> PDB generation is needed for making crash reports have readable > >>>> >> >> stack > >>>> >> >> traces (and for debugging, of course).
> >>>> >> >>> I mainly use Linux dev environment because build time is faster > >>>> >> >>> than > >>>> >> >>> Windows.
> >>>> >> >>> As you know, link time on Windows is extremely slow!! > >>>> >> >>> So I always disabled pdb generation and no opt ref in Release > mode > >>>> >> >>> manually.
> >>>> >> >>> I don't know why the Release setting still enable pdb > generation > >>>> >> >>> as > >>>> >> >>> default though. > >>>> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link > >>>> >> >>> time > >>>> >> >>> is > >>>> >> >>> shorten. > >>>> >> >>> Of course, it might help for debugger, but I don't use debugger > >>>> >> >>> these > >>>> >> >>> days.
> >>>> >> >>> Thanks,
> >>>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano < > c...@chromium.org> > >>>> >> >>> wrote: > >>>> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and > >>>> >> >>> > debug > >>>> >> >>> > build.
> >>>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the > >>>> >> >>> > "ultimate" > >>>> >> >>> > edition.
> >>>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: > >>>> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> > wrote:
> >>>> >> >>> >> > - The "max number of parallel project builds" is > actually > >>>> >> >>> >> > number > >>>> >> >>> >> > of > >>>> >> >>> >> > VCBuildHelper.exe instances, not the number of > concurrent > >>>> >> >>> >> > cl.exe. > >>>> >> >>> >> > Similar > >>>> >> >>> >> > things happened in VC 2010: this number indicates > number > >>>> >> >>> >> > of > >>>> >> >>> >> > MSBuild.exe > >>>> >> >>> >> > instances, not cl.exe. See attached picture.
> >>>> >> >>> >> The number of cl/link instances is controlled by the /MP > switch > >>>> >> >>> >> and > >>>> >> >>> >> set to use all your effective processors by default if you > >>>> >> >>> >> don't > >>>> >> >>> >> specify a number - which is what chromium currently does; > >>>> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. > You > >>>> >> >>> >> can > >>>> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and > >>>> >> >>> >> manually > >>>> >> >>> >> setting it yourself through 'msvs_settings' -> > >>>> >> >>> >> 'VCCLCompilerTool' > >>>> >> >>> >> -> > >>>> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of > >>>> >> >>> >> cl.exe > >>>> >> >>> >> etc. > >>>> >> >>> >> processes you want running per project.
> On Tue, Apr 19, 2011 at 1:21 PM, Lei Zhang <thes...@chromium.org> wrote:
>> I don't think we have shared configuration try bots for either Windows or >> Linux.
>> On Tue, Apr 19, 2011 at 1:19 PM, Mike Reed <r...@google.com> wrote: >> > What bot will exercise this? i.e. gcl try foo --bot=?
>> > On Tue, Apr 19, 2011 at 4:14 PM, Vangelis Kokkevis <vange...@google.com> >> wrote: >> >> Just wanted to mention that switching to the multi-dll build in this >> past >> >> couple of weeks has been a tremendous productivity boost. Not only the >> code >> >> builds faster (the webkit library links in under 10 secs) but also now >> the >> >> VS debugger seems to be able to load and run chrome within seconds. If >> >> windows is your primary development platform, do yourself a favor and >> give >> >> it a try! >> >> Many kudos to Brian for bringing it up. >> >> Vangelis >> >> PS I also used the utility that Brian mentions to set the file cache >> size to >> >> 2GB. I don't know how much that plays into the speed improvement.
>> >> On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> >> wrote:
>> >>> Sure, this is all I did: >> >>> To boost the file cache I used this tool: >> >>> http://www.analogx.com/contents/download/System/cb/Freeware.htm >> >>> The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. >> >>> To enable the Multi-DLL build I put: >> >>> {'variables': {'component': 'shared_library'}} >> >>> in c:\users\<my username>\.gyp\include.gypi >> >>> I had to blow-away my <chrome>\src\build\Debug >> >>> and <chrome>\src\build\Release dirs before the first builds after >> switching >> >>> to Multi-DLL. >> >>> I also have my chrome tree on a different drive than my OS. >> >>> Brian
>> >>> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> >> wrote:
>> >>>> SWEETNESS! >> >>>> Please share with the rest of us how to set this up.
>> >>>> -Scott
>> >>>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> >> >>>> wrote: >> >>>> > I've been using the Multi-DLL build and used a tool to boost my >> system >> >>>> > file >> >>>> > cache to 2GB. If I touch a file in WebKit >> >>>> > (GraphicsContext3DChromium.cpp) >> >>>> > and build the Chrome target in Debug from VS 2008 it takes 10 >> seconds >> >>>> > or >> >>>> > less to complete. This is with a hot cache (I've built several >> times >> >>>> > recently). >> >>>> > Brian
>> >>>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano < >> takano.na...@gmail.com> >> >>>> > wrote:
>> >>>> >> Of course, I know PDB generation purpose.
>> >>>> >> But I agree with Steve. Of course, we can change manually setting, >> but >> >>>> >> it's convenient if we have.
>> >>>> >> Thanks,
>> >>>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >> >>>> >> <vand...@chromium.org> wrote: >> >>>> >> > Should we have a Release-NoSymbol target for faster development >> >>>> >> > builds? >> >>>> >> > -- >> >>>> >> > Steve
>> >>>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >> >>>> >> > <sanje...@chromium.org> wrote:
>> >>>> >> >> PDB generation is needed for making crash reports have readable >> >>>> >> >> stack >> >>>> >> >> traces (and for debugging, of course).
>> >>>> >> >>> I mainly use Linux dev environment because build time is >> faster >> >>>> >> >>> than >> >>>> >> >>> Windows.
>> >>>> >> >>> As you know, link time on Windows is extremely slow!! >> >>>> >> >>> So I always disabled pdb generation and no opt ref in Release >> mode >> >>>> >> >>> manually.
>> >>>> >> >>> I don't know why the Release setting still enable pdb >> generation >> >>>> >> >>> as >> >>>> >> >>> default though. >> >>>> >> >>> Once disable them, mspdbsrv.exe consumes less memories and >> link >> >>>> >> >>> time >> >>>> >> >>> is >> >>>> >> >>> shorten. >> >>>> >> >>> Of course, it might help for debugger, but I don't use >> debugger >> >>>> >> >>> these >> >>>> >> >>> days.
>> >>>> >> >>> Thanks,
>> >>>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano < >> c...@chromium.org> >> >>>> >> >>> wrote: >> >>>> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and >> >>>> >> >>> > debug >> >>>> >> >>> > build.
>> >>>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the >> >>>> >> >>> > "ultimate" >> >>>> >> >>> > edition.
>> >>>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> >> wrote: >> >>>> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> >> wrote:
>> >>>> >> >>> >> > - The "max number of parallel project builds" is >> actually >> >>>> >> >>> >> > number >> >>>> >> >>> >> > of >> >>>> >> >>> >> > VCBuildHelper.exe instances, not the number of >> concurrent >> >>>> >> >>> >> > cl.exe. >> >>>> >> >>> >> > Similar >> >>>> >> >>> >> > things happened in VC 2010: this number indicates >> number >> >>>> >> >>> >> > of >> >>>> >> >>> >> > MSBuild.exe >> >>>> >> >>> >> > instances, not cl.exe. See attached picture.
>> >>>> >> >>> >> The number of cl/link instances is controlled by the /MP >> switch >> >>>> >> >>> >> and >> >>>> >> >>> >> set to use all your effective processors by default if you >> >>>> >> >>> >> don't >> >>>> >> >>> >> specify a number - which is what chromium currently does; >> >>>> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. >> You >> >>>> >> >>> >> can >> >>>> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and >> >>>> >> >>> >> manually >> >>>> >> >>> >> setting it yourself through 'msvs_settings' -> >> >>>> >> >>> >> 'VCCLCompilerTool' >> >>>> >> >>> >> -> >> >>>> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of >> >>>> >> >>> >> cl.exe >> >>>> >> >>> >> etc. >> >>>> >> >>> >> processes you want running per project.
Agreed, but when the multi-dll build was broke for the better part of a day last week I lost faith. Can we treat the multi-dll build like any other compile bots?
On Tue, Apr 19, 2011 at 1:14 PM, Vangelis Kokkevis <vange...@google.com> wrote: > Just wanted to mention that switching to the multi-dll build in this past > couple of weeks has been a tremendous productivity boost. Not only the code > builds faster (the webkit library links in under 10 secs) but also now the > VS debugger seems to be able to load and run chrome within seconds. If > windows is your primary development platform, do yourself a favor and give > it a try! > Many kudos to Brian for bringing it up. > Vangelis > PS I also used the utility that Brian mentions to set the file cache size to > 2GB. I don't know how much that plays into the speed improvement.
> On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> wrote:
>> Sure, this is all I did: >> To boost the file cache I used this tool: >> http://www.analogx.com/contents/download/System/cb/Freeware.htm >> The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. >> To enable the Multi-DLL build I put: >> {'variables': {'component': 'shared_library'}} >> in c:\users\<my username>\.gyp\include.gypi >> I had to blow-away my <chrome>\src\build\Debug >> and <chrome>\src\build\Release dirs before the first builds after switching >> to Multi-DLL. >> I also have my chrome tree on a different drive than my OS. >> Brian
>> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote:
>>> SWEETNESS! >>> Please share with the rest of us how to set this up.
>>> -Scott
>>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> >>> wrote: >>> > I've been using the Multi-DLL build and used a tool to boost my system >>> > file >>> > cache to 2GB. If I touch a file in WebKit >>> > (GraphicsContext3DChromium.cpp) >>> > and build the Chrome target in Debug from VS 2008 it takes 10 seconds >>> > or >>> > less to complete. This is with a hot cache (I've built several times >>> > recently). >>> > Brian
>>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> >>> > wrote:
>>> >> Of course, I know PDB generation purpose.
>>> >> But I agree with Steve. Of course, we can change manually setting, but >>> >> it's convenient if we have.
>>> >> Thanks,
>>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >>> >> <vand...@chromium.org> wrote: >>> >> > Should we have a Release-NoSymbol target for faster development >>> >> > builds? >>> >> > -- >>> >> > Steve
>>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >>> >> > <sanje...@chromium.org> wrote:
>>> >> >> PDB generation is needed for making crash reports have readable >>> >> >> stack >>> >> >> traces (and for debugging, of course).
>>> >> >>> I mainly use Linux dev environment because build time is faster >>> >> >>> than >>> >> >>> Windows.
>>> >> >>> As you know, link time on Windows is extremely slow!! >>> >> >>> So I always disabled pdb generation and no opt ref in Release mode >>> >> >>> manually.
>>> >> >>> I don't know why the Release setting still enable pdb generation >>> >> >>> as >>> >> >>> default though. >>> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link >>> >> >>> time >>> >> >>> is >>> >> >>> shorten. >>> >> >>> Of course, it might help for debugger, but I don't use debugger >>> >> >>> these >>> >> >>> days.
>>> >> >>> Thanks,
>>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >>> >> >>> wrote: >>> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and >>> >> >>> > debug >>> >> >>> > build.
>>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the >>> >> >>> > "ultimate" >>> >> >>> > edition.
>>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >>> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>>> >> >>> >> > - The "max number of parallel project builds" is actually >>> >> >>> >> > number >>> >> >>> >> > of >>> >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >>> >> >>> >> > cl.exe. >>> >> >>> >> > Similar >>> >> >>> >> > things happened in VC 2010: this number indicates number >>> >> >>> >> > of >>> >> >>> >> > MSBuild.exe >>> >> >>> >> > instances, not cl.exe. See attached picture.
>>> >> >>> >> The number of cl/link instances is controlled by the /MP switch >>> >> >>> >> and >>> >> >>> >> set to use all your effective processors by default if you >>> >> >>> >> don't >>> >> >>> >> specify a number - which is what chromium currently does; >>> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You >>> >> >>> >> can >>> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and >>> >> >>> >> manually >>> >> >>> >> setting it yourself through 'msvs_settings' -> >>> >> >>> >> 'VCCLCompilerTool' >>> >> >>> >> -> >>> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of >>> >> >>> >> cl.exe >>> >> >>> >> etc. >>> >> >>> >> processes you want running per project.
>>> >> >>> >> For example, your include.gypi file could be this for limiting >>> >> >>> >> it >>> >> >>> >> to >>> >> >>> >> 12 processes per project: >>> >> >>> >> ------------- >>> >> >>> >> { >>> >> >>> >> 'variables': { >>> >> >>> >> 'msvs_multi_core_compile': 0, >>> >> >>> >> }, >>> >> >>> >> 'target_defaults': { >>> >> >>> >> 'msvs_settings': { >>> >> >>> >> 'VCCLCompilerTool': { >>> >> >>> >> 'AdditionalOptions': ['/MP12'], >>> >> >>> >> }, >>> >> >>> >> }, >>> >> >>> >> },}
On Tue, Apr 19, 2011 at 2:00 PM, Scott Violet <s...@chromium.org> wrote: > Agreed, but when the multi-dll build was broke for the better part of > a day last week I lost faith. Can we treat the multi-dll build like > any other compile bots?
> -Scott
> On Tue, Apr 19, 2011 at 1:14 PM, Vangelis Kokkevis <vange...@google.com> > wrote: > > Just wanted to mention that switching to the multi-dll build in this past > > couple of weeks has been a tremendous productivity boost. Not only the > code > > builds faster (the webkit library links in under 10 secs) but also now > the > > VS debugger seems to be able to load and run chrome within seconds. If > > windows is your primary development platform, do yourself a favor and > give > > it a try! > > Many kudos to Brian for bringing it up. > > Vangelis > > PS I also used the utility that Brian mentions to set the file cache size > to > > 2GB. I don't know how much that plays into the speed improvement.
> > On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> > wrote:
> >> Sure, this is all I did: > >> To boost the file cache I used this tool: > >> http://www.analogx.com/contents/download/System/cb/Freeware.htm > >> The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. > >> To enable the Multi-DLL build I put: > >> {'variables': {'component': 'shared_library'}} > >> in c:\users\<my username>\.gyp\include.gypi > >> I had to blow-away my <chrome>\src\build\Debug > >> and <chrome>\src\build\Release dirs before the first builds after > switching > >> to Multi-DLL. > >> I also have my chrome tree on a different drive than my OS. > >> Brian
> >> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote:
> >>> SWEETNESS! > >>> Please share with the rest of us how to set this up.
> >>> -Scott
> >>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> > >>> wrote: > >>> > I've been using the Multi-DLL build and used a tool to boost my > system > >>> > file > >>> > cache to 2GB. If I touch a file in WebKit > >>> > (GraphicsContext3DChromium.cpp) > >>> > and build the Chrome target in Debug from VS 2008 it takes 10 seconds > >>> > or > >>> > less to complete. This is with a hot cache (I've built several times > >>> > recently). > >>> > Brian
> >>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano < > takano.na...@gmail.com> > >>> > wrote:
> >>> >> Of course, I know PDB generation purpose.
> >>> >> But I agree with Steve. Of course, we can change manually setting, > but > >>> >> it's convenient if we have.
> >>> >> Thanks,
> >>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart > >>> >> <vand...@chromium.org> wrote: > >>> >> > Should we have a Release-NoSymbol target for faster development > >>> >> > builds? > >>> >> > -- > >>> >> > Steve
> >>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan > >>> >> > <sanje...@chromium.org> wrote:
> >>> >> >> PDB generation is needed for making crash reports have readable > >>> >> >> stack > >>> >> >> traces (and for debugging, of course).
> >>> >> >>> I mainly use Linux dev environment because build time is faster > >>> >> >>> than > >>> >> >>> Windows.
> >>> >> >>> As you know, link time on Windows is extremely slow!! > >>> >> >>> So I always disabled pdb generation and no opt ref in Release > mode > >>> >> >>> manually.
> >>> >> >>> I don't know why the Release setting still enable pdb generation > >>> >> >>> as > >>> >> >>> default though. > >>> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link > >>> >> >>> time > >>> >> >>> is > >>> >> >>> shorten. > >>> >> >>> Of course, it might help for debugger, but I don't use debugger > >>> >> >>> these > >>> >> >>> days.
> >>> >> >>> Thanks,
> >>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano < > c...@chromium.org> > >>> >> >>> wrote: > >>> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and > >>> >> >>> > debug > >>> >> >>> > build.
> >>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the > >>> >> >>> > "ultimate" > >>> >> >>> > edition.
> >>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: > >>> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> > wrote:
> >>> >> >>> >> > - The "max number of parallel project builds" is > actually > >>> >> >>> >> > number > >>> >> >>> >> > of > >>> >> >>> >> > VCBuildHelper.exe instances, not the number of > concurrent > >>> >> >>> >> > cl.exe. > >>> >> >>> >> > Similar > >>> >> >>> >> > things happened in VC 2010: this number indicates number > >>> >> >>> >> > of > >>> >> >>> >> > MSBuild.exe > >>> >> >>> >> > instances, not cl.exe. See attached picture.
> >>> >> >>> >> The number of cl/link instances is controlled by the /MP > switch > >>> >> >>> >> and > >>> >> >>> >> set to use all your effective processors by default if you > >>> >> >>> >> don't > >>> >> >>> >> specify a number - which is what chromium currently does; > >>> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. > You > >>> >> >>> >> can > >>> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and > >>> >> >>> >> manually > >>> >> >>> >> setting it yourself through 'msvs_settings' -> > >>> >> >>> >> 'VCCLCompilerTool' > >>> >> >>> >> -> > >>> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of > >>> >> >>> >> cl.exe > >>> >> >>> >> etc. > >>> >> >>> >> processes you want running per project.
On Tue, Apr 19, 2011 at 5:00 PM, Scott Violet <s...@chromium.org> wrote: > Agreed, but when the multi-dll build was broke for the better part of > a day last week I lost faith. Can we treat the multi-dll build like > any other compile bots?
> -Scott
> On Tue, Apr 19, 2011 at 1:14 PM, Vangelis Kokkevis <vange...@google.com> wrote: >> Just wanted to mention that switching to the multi-dll build in this past >> couple of weeks has been a tremendous productivity boost. Not only the code >> builds faster (the webkit library links in under 10 secs) but also now the >> VS debugger seems to be able to load and run chrome within seconds. If >> windows is your primary development platform, do yourself a favor and give >> it a try! >> Many kudos to Brian for bringing it up. >> Vangelis >> PS I also used the utility that Brian mentions to set the file cache size to >> 2GB. I don't know how much that plays into the speed improvement.
>> On Wed, Apr 13, 2011 at 2:20 PM, Brian Salomon <bsalo...@google.com> wrote:
>>> Sure, this is all I did: >>> To boost the file cache I used this tool: >>> http://www.analogx.com/contents/download/System/cb/Freeware.htm >>> The max allowed seems to be 2GB. My Z600 system has 12GB of RAM. >>> To enable the Multi-DLL build I put: >>> {'variables': {'component': 'shared_library'}} >>> in c:\users\<my username>\.gyp\include.gypi >>> I had to blow-away my <chrome>\src\build\Debug >>> and <chrome>\src\build\Release dirs before the first builds after switching >>> to Multi-DLL. >>> I also have my chrome tree on a different drive than my OS. >>> Brian
>>> On Wed, Apr 13, 2011 at 5:09 PM, Scott Violet <s...@chromium.org> wrote:
>>>> SWEETNESS! >>>> Please share with the rest of us how to set this up.
>>>> -Scott
>>>> On Wed, Apr 13, 2011 at 1:44 PM, Brian Salomon <bsalo...@google.com> >>>> wrote: >>>> > I've been using the Multi-DLL build and used a tool to boost my system >>>> > file >>>> > cache to 2GB. If I touch a file in WebKit >>>> > (GraphicsContext3DChromium.cpp) >>>> > and build the Chrome target in Debug from VS 2008 it takes 10 seconds >>>> > or >>>> > less to complete. This is with a hot cache (I've built several times >>>> > recently). >>>> > Brian
>>>> > On Wed, Apr 13, 2011 at 4:19 PM, Naoki Takano <takano.na...@gmail.com> >>>> > wrote:
>>>> >> Of course, I know PDB generation purpose.
>>>> >> But I agree with Steve. Of course, we can change manually setting, but >>>> >> it's convenient if we have.
>>>> >> Thanks,
>>>> >> On Wed, Apr 13, 2011 at 12:41 PM, Steve VanDeBogart >>>> >> <vand...@chromium.org> wrote: >>>> >> > Should we have a Release-NoSymbol target for faster development >>>> >> > builds? >>>> >> > -- >>>> >> > Steve
>>>> >> > On Wed, Apr 13, 2011 at 12:38 PM, Sanjeev Radhakrishnan >>>> >> > <sanje...@chromium.org> wrote:
>>>> >> >> PDB generation is needed for making crash reports have readable >>>> >> >> stack >>>> >> >> traces (and for debugging, of course).
>>>> >> >>> I mainly use Linux dev environment because build time is faster >>>> >> >>> than >>>> >> >>> Windows.
>>>> >> >>> As you know, link time on Windows is extremely slow!! >>>> >> >>> So I always disabled pdb generation and no opt ref in Release mode >>>> >> >>> manually.
>>>> >> >>> I don't know why the Release setting still enable pdb generation >>>> >> >>> as >>>> >> >>> default though. >>>> >> >>> Once disable them, mspdbsrv.exe consumes less memories and link >>>> >> >>> time >>>> >> >>> is >>>> >> >>> shorten. >>>> >> >>> Of course, it might help for debugger, but I don't use debugger >>>> >> >>> these >>>> >> >>> days.
>>>> >> >>> Thanks,
>>>> >> >>> On Tue, Apr 12, 2011 at 7:29 PM, Carlos Pizano <c...@chromium.org> >>>> >> >>> wrote: >>>> >> >>> > I report 2.5 minutes with VS2010 for a single .cc touch and >>>> >> >>> > debug >>>> >> >>> > build.
>>>> >> >>> > BTW, VS2010 SP1 builds chrome just fine. I do have the >>>> >> >>> > "ultimate" >>>> >> >>> > edition.
>>>> >> >>> > On Apr 12, 8:01 am, Ryan Norton <rnorto...@gmail.com> wrote: >>>> >> >>> >> On Apr 11, 2:42 pm, Arthur Hsu <arthur...@chromium.org> wrote:
>>>> >> >>> >> > - The "max number of parallel project builds" is actually >>>> >> >>> >> > number >>>> >> >>> >> > of >>>> >> >>> >> > VCBuildHelper.exe instances, not the number of concurrent >>>> >> >>> >> > cl.exe. >>>> >> >>> >> > Similar >>>> >> >>> >> > things happened in VC 2010: this number indicates number >>>> >> >>> >> > of >>>> >> >>> >> > MSBuild.exe >>>> >> >>> >> > instances, not cl.exe. See attached picture.
>>>> >> >>> >> The number of cl/link instances is controlled by the /MP switch >>>> >> >>> >> and >>>> >> >>> >> set to use all your effective processors by default if you >>>> >> >>> >> don't >>>> >> >>> >> specify a number - which is what chromium currently does; >>>> >> >>> >> seehttp://msdn.microsoft.com/en-us/library/bb385193.aspx. You >>>> >> >>> >> can >>>> >> >>> >> override it by setting 'msvs_multi_core_compile': 0 and >>>> >> >>> >> manually >>>> >> >>> >> setting it yourself through 'msvs_settings' -> >>>> >> >>> >> 'VCCLCompilerTool' >>>> >> >>> >> -> >>>> >> >>> >> 'AdditionalOptions': ['/MP***']; *** would be the max # of >>>> >> >>> >> cl.exe >>>> >> >>> >> etc. >>>> >> >>> >> processes you want running per project.
>>>> >> >>> >> For example, your include.gypi file could be this for limiting >>>> >> >>> >> it >>>> >> >>> >> to >>>> >> >>> >> 12 processes per project: >>>> >> >>> >> ------------- >>>> >> >>> >> { >>>> >> >>> >> 'variables': { >>>> >> >>> >> 'msvs_multi_core_compile': 0, >>>> >> >>> >> }, >>>> >> >>> >> 'target_defaults': { >>>> >> >>> >> 'msvs_settings': { >>>> >> >>> >> 'VCCLCompilerTool': { >>>> >> >>> >> 'AdditionalOptions': ['/MP12'], >>>> >> >>> >> }, >>>> >> >>> >> }, >>>> >> >>> >> },}
