I have followed instructions here:
https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md
to compile chormium on Windows 7 x64.
It takes some long time to compile, but the problem is not the slow compiling, the problem is in fact that when the browser i built, it runs very, very slow. Is uses much more RAM then usual Chome and it even cannot run on Virtual Machine with 3GB of RAM (shows error).
How can I compile Chromium that can run normally without performanse problems?
If you built it according to instructions then I suppose the problem was in "is_debug = true".
In case you want build browser for normal usage try to change this string from dev manual from:
gn gen out/Default --args="is_component_build = true is_debug = true"
to
gn gen out/Default --args="is_official = true"
"is_officail" flag makes a lot of optimizasions.
see https://www.chromium.org/developers/gn-build-configuration
for full gn-docs
you most likely need
is_official_build = true
is_debug = false
dcheck_always_on = false
blink_symbol_level = 0
symbol_level = 0
in your gn args.
Related
I want to compile Chromium for windows with different patches from different projects for myself (at least for today). I follow this official instruction:
https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md
All steps successfully passed, but i get awful low perfomance. In speeDOMeter benchmark (https://browserbench.org/Speedometer2.0/) my build get only 5 points, while official build get 116! This is commands for GIT what i use:
gclient
mkdir chromium && cd chromium
fetch --no-history chromium
cd src
gn gen --ide=vs out/Default "--args=target_cpu=\"x86\""
autoninja -C out/Default chrome -j 6
What i was try and this is not help:
Delete depot tools folder, and start over
Decrease -j from 10 to 8 and to 6
Delete argument --ide=vs
Fetch with history
Use command "gn gen" without --args part
Disable windows defender & firewall
As Asesh correctly noted, the problem was in debug mode. But adding key "is_debug=false" to gn gen command is not enough. The best solution will be the adding "is_official_build=true" key. Here is description:
is_official_build
Current value (from the default) = false
From //build/config/BUILDCONFIG.gn:136
Set to enable the official build level of optimization. This has nothing
to do with branding, but enables an additional level of optimization above
release (!is_debug). This might be better expressed as a tri-state
(debug, release, official) but for historical reasons there are two
separate flags.
IMPORTANT NOTE: (!is_debug) is *not* sufficient to get satisfying
performance. In particular, DCHECK()s are still enabled for release builds,
which can halve overall performance, and do increase memory usage. Always
set "is_official_build" to true for any build intended to ship to end-users.
Thanks Asesh for pointing me in the right direction.
I'm new to Julia and, after a suggestion, I started using nightly build 1.6.0-DEV.1371 due to the high loading time of packages in Julia 1.5.2.
So I tried to change the default directory of DEPOT_PATH and copied all files from ~/.julia to /opt/julia (owned by my user). Now, if I start Julia using the default directory and run the code below, it takes about 4 seconds. However, when I start julia in the new directory (JULIA_DEPOT_PATH=/opt/julia julia), the same code takes incredible 83 seconds. The same happens with Julia 1.5.2 (17s in the default directory, 200s in the new directory).
This is the code I'm using to measure the time.
t = time(); using Plots; time() - t
Is there some explanation about this strange (and annoying) behavior?
My Platform Info:
Platform Info:
OS: Linux (x86_64-pc-linux-gnu)
CPU: Intel(R) Core(TM) i3-6100U CPU # 2.30GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-9.0.1 (ORCJIT, skylake)
And I'm using a SSD.
There is a good chance that now you are having files from your previous Julia installation with the new Julia's JULIA_DEPOT_PATH. The normal approach is to set JULIA_DEPOT_PATH to an empty folder and then install them there.
Regarding startup times there are the following things you can do:
Precompile package (this is also happening when you use a new version of the package for the first time)
using Pkg
pkg"precompile"
Once Plots is precompiled it still takes around 10s to load each time.
If the above time is unacceptable build-in your Plots into Julia system image.
using PackageCompiler
create_sysimage(:Plots, sysimage_path="sys_plots.so", precompile_execution_file="precompile_plots.jl")
For the precompile_plots.jl you could use commands that you use regularly or perhaps test sets from Plots.jl.
Once done you will be starting Julia with the following comand:
julia --sysimage sys_plots.so
Building the system image takes long, however once done, loading Plots.jl will be a matter of milliseconds.
More information can be found here:
package compiler tutorial https://julialang.github.io/PackageCompiler.jl/dev/examples/plots/
excellent tutorial video https://live.juliacon.org/talk/Z8TE39
I built my own version of Chromium using official instruction with very slight changes in the code that do not touch the core things. When I try to launch it on Windows 10 (tried Home and LTSC), is shows "RESULT_CODE_MISSING_DATA" error on each page, including internal ones, like "settings".
The build works on Windows 10 correctly if I launch it with "compatibility to Windows 8" option, but that's a bad option as it launches with additional borders, maybe it's because of Metro UI:
enter image description here
The build launches on Windows 7 well without any additional changes.
I tried to build 82.x.x.x and 81.x.x.x builds, they all emerge this error on Windows 10.
I tried to do builds on multiple OS (Win7, Win10), the error still presents.
my args.gn:
is_debug = false
is_component_build = false
enable_nacl = false
symbol_level = 1
target_cpu = "x86" # I tried x64, same problem
blink_symbol_level = 1
proprietary_codecs = true
ffmpeg_branding = "Chrome"
is_component_ffmpeg=true
is_official_build=true
Ok, after several build tries I built chromium well-working after removing the is_component_ffmpeg=true flag from args.gn.
Thanks Asesh for helping.
I don't know if someone else is running into this problem. I have this main.go file:
package main
import "fmt"
func main() {
fmt.Println("hello world")
}
when I run go build, it takes 5 secs to run it (regardless if it is the first time I run it or if it is the second time)
PS> Measure-Command {Start-Process go build -wait}
Days : 0
Hours : 0
Minutes : 0
Seconds : 5
Milliseconds : 151
Ticks : 51514117
TotalDays : 5.96228206018519E-05
TotalHours : 0.00143094769444444
TotalMinutes : 0.0858568616666667
TotalSeconds : 5.1514117
TotalMilliseconds : 5151.4117
But when I run it on a linux machine:
time go build
real 0m2.017s
user 0m0.054s
sys 0m1.915s
and when I run it for the second time:
time go build
real 0m0.120s
user 0m0.072s
sys 0m0.088s
This is not only build, but also some of go tools such as fmt. It takes 0.12 seconds on linux, but almost 3 seconds on windows. Other tools like guru, gocode, etc. suffer the same problem, making code development very slow.
I'm using golang 1.11. I'm using an SSD and everything is running locally. Sorry I wish I could be more helpful but I really have no idea where to start to debug this.
Does anyone has an idea what's going on?
It seems that the build cache is disabled on your Windows and enabled on your Linux.
Go build keeps the result of compilations and reuse it if the .go file hasn't changed. That's why your second build is so fast in Linux.
If you disable it, not only your code, but also all the dependancies must be recompiled each time. Thus even if you change your code, all the libs (here "fmt") are already in cache.
To test it, run go clean -cache before the go build on Linux, and see if the time correspond to the time on your Windows. Then if it matches, you have to find why the build cache is disabled on Windows.
You can see the cache directory by typing go env GOCACHE. If the response is off, the cache is off. Otherwise verify that the repository exists and it has the right permissions.
You can choos the cache directory by setting the value of the GOCACHE environment variable (sorry I don't know how to do this in Windows).
I was having same issue. Turns out I had a really big directory with 1000s of large files in the same location where the binary was. Moving the big dir out to a different location resolved the issue. This was in a macOS.
I am using travis-ci and biicode to build my project who is depending on boost log. But boost log times are longer than 10 min so I get this message:
No output has been received in the last 10 minutes, this potentially indicates a
stalled build or something wrong with the build itself.
The build has been terminated
The build is working correctly, it's just that boost log is really long to compile with limited resources (I tried to compile it on a VM with 1 CPU and 2GB of RAM and it took almost more than 15 min)
I know this is happening because there is not enough verbose going on so I tried the following flags:
>bii cpp:build -- VERBOSE=1
In the CMakeList.txt, set BII_BOOST_VERBOSE ON as mentionnened here
Set BOOST_LOG_COMPILE_FAST_ON as explained here
Using travis_wait
Actually travis_wait seems to be the correct solution but when I put it in my .travis.yml like this
script: travis_wait bii cpp:build
It does actually doesn't output logs like usually and just time out after 20 min. I don't think the actual building is taking place
What is the correct way to handle this problem?
This is a known issue, Boost.Log takes a long time to compile.
You can use travis_wait to call bii cpp:configure, but I'm with you, I need log feedback (No pun intended). However, I have tried that too and leaded to >50min build, which means travis aborts build on free accounts :( Of course my repo does not build Boost.Log only.
Just as a note, here's part of the settings.py file from the boost-biicode repo:
#Boost.Log takes so much time to compile, leads to timeouts on Travis CI
#It was tested on Windows and linux, works 'ok' (Be careful with linking settings)
if args.ci: del packages['examples/boost-log']
I'm currently working on a solution, launching asynchronous builds while printing progress. Check this issue. It will be ready for this week :)
To speed-up your build, try to play with BII_BOOST_BUILD_J variable to set the number of threads you want for building Boost components. Here's an example:
script:
- bii cpp:configure -DBII_BOOST_BUILD_J=4
Be careful, more threads means more RAM needed to compile at a time. Be sure you don't make the travis job VM go out of memory.