search

dexcz / libyuv

Automatically exported from code.google.com/p/libyuv
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

set DEPOT_TOOLS_WIN_TOOLCHAIN=0 causes gyp_libyuv to be slow #438

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

set GYP_DEFINES=target_arch=ia32 libyuv_enable_svn=1
set DEPOT_TOOLS_WIN_TOOLCHAIN=0
call python gyp_libyuv -fninja -G msvs_version=2013 libyuv_test.gyp

What is the expected output? 
gyp_libyuv should be fast

What do you see instead?
gyp_libyuv takes about 30 seconds.

Please use labels and text to provide additional information.
A build without DEPOT_TOOLS_WIN_TOOLCHAIN is fast

set DEPOT_TOOLS_WIN_TOOLCHAIN=0 is required for compilers other than vs2013.

set GYP_DEFINES=target_arch=ia32 libyuv_enable_svn=1
call python gyp_libyuv -fninja -G msvs_version=2013 libyuv_test.gyp

Original issue reported on code.google.com by fbarch...@google.com on 6 May 2015 at 12:33

GoogleCodeExporter commented 9 years ago 
I can't reproduce this is on a non-corp machine:

D:\src\libyuv>set GYP_DEFINES=target_arch=ia32 libyuv_enable_svn=1

D:\src\libyuv\trunk>set DEPOT_TOOLS_WIN_TOOLCHAIN=0

D:\src\libyuv\trunk>tim cmd /c call python gyp_libyuv -fninja -G 
msvs_version=2013 libyuv_test.gyp
Updating projects from gyp files...

real: 0m2.954s
qpc: 2951467us

D:\src\libyuv\trunk>set DEPOT_TOOLS_WIN_TOOLCHAIN=

D:\src\libyuv\trunk>tim cmd /c call python gyp_libyuv -fninja -G 
msvs_version=2013 libyuv_test.gyp
Updating projects from gyp files...

real: 0m2.297s
qpc: 2310707us

----------

So I think it must be something to do with either your local machine, or an app 
installed by corp policy.

Original comment by scottmg@chromium.org on 6 May 2015 at 1:00

GoogleCodeExporter commented 9 years ago 
Reconfirming gyp is slow on corp machine

d:\src\libyuv\trunk>start vs.exe +new source\row_neon64.cc
d:\src\libyuv\trunk>set GYP_DEFINES=target_arch=ia32 libyuv_enable_svn=1
d:\src\libyuv\trunk>set DEPOT_TOOLS_WIN_TOOLCHAIN=0
d:\src\libyuv\trunk>timex python gyp_libyuv -fninja -G msvs_version=2013 
libyuv_test.gyp
Updating projects from gyp files...
TIMEX 28275.00 ms (28.27 seconds), python gyp_libyuv -fninja -G 
msvs_version=2013 libyuv_test.gyp

d:\src\libyuv\trunk>set DEPOT_TOOLS_WIN_TOOLCHAIN=
d:\src\libyuv\trunk>timex python gyp_libyuv -fninja -G msvs_version=2013 
libyuv_test.gyp
Updating projects from gyp files...
TIMEX 3655.00 ms (3.65 seconds), python gyp_libyuv -fninja -G msvs_version=2013 
libyuv_test.gyp

Original comment by fbarch...@google.com on 7 May 2015 at 5:32

GoogleCodeExporter commented 9 years ago

Original comment by fbarch...@google.com on 7 May 2015 at 5:34

GoogleCodeExporter commented 9 years ago 
Consider grabbing two ETW traces, one with and one without 
DEPOT_TOOLS_WIN_TOOLCHAIN=0. Share them on Google drive and I can take a look. 
UIforETW in Tracing to File mode should make this easy.

Original comment by brucedaw...@chromium.org on 7 May 2015 at 6:09

GoogleCodeExporter commented 9 years ago 
Testing with a Chromium repo shows that set DEPOT_TOOLS_WIN_TOOLCHAIN=0 adds 
about 20 seconds to the time. Two runs were done with it clear and then two 
runs with it set. GYP_MSVS_VERSION was set to 2013 so that the same compiler 
version would be configured. No builds were done.

The tests without DEPOT_TOOLS_WIN_TOOLCHAIN ran at an extremely reliable 1 min 
0.5 s.
The tests with DEPOT_TOOLS_WIN_TOOLCHAIN=0 ran at an extremely reliable 1 min 
20.5 s.

So, there is a fixed 20 second penalty for having DEPOT_TOOLS_WIN_TOOLCHAIN=0. 
The 33% increase will be difficult to profile, but if Frank gets an ETW profile 
of the ~400% slowdown in libyuv it should be easy to see what the difference 
is, and then decide if we care.

My Chromium test batch file is shown here:

@set starttime=%time%
python build\gyp_chromium
@echo From %starttime% to %time%

Original comment by brucedaw...@chromium.org on 7 May 2015 at 11:36