I'm having a problem trying to build mozilla firefox. Despite the fact that my system is quite decent (i5 processor, 16 gb ram, ssd) , the build is very slow. I've used mk_add_options MOZ_MAKE_FLAGS="-j4" option in the mozconfig but my CPU is still at 1-2% of usage.
Is there something that I am missing?
The initial build can take from 10 minutes to more than an hour, depending on the OS, the build machine specs, and the build configuration.
Has your build finished at all? What do you call "slow"?
What OS are you building on? Windows, for example, is much slower to build.
What version of Firefox are you building (m-c tip? an old version?)
What's your build configuration (mozconfig)? Are you doing a debug or a release build? Any non-standard options? Did you try artifact builds?
Paste the build log, in particular it prints how much resources it took to build just before the end of the build.
Do you have A/V or other system software? Did you instruct it to ignore the objdir?
Related
I was running an API 33 pixel 6 x64_86 that returned an error for a couple of apps I was trying to install: [INSTALL_FAILED_NO_MATCHING_ABIS: Failed to extract native libraries, res=-113]
I found these run on armeabi-v7a. So I tried a second avd when I ran into a bunch of more problems.
The api 33 wouldnt run an armeabi-v7a, so I tried different combinations. Unfortunately every one of them had the same prompt that I should run an x86 image on an x86 host as its 10x faster. When I forced one to run on Nougat 7.1.1 armeabi-v7a, a nexus, the avd ran snail slow taking almost 10 mins to just start up and I could ultimately install neither of the apps.
Im now out of ideas. Can anyone help and mostly importantly, is there any way I can run the armeabi on the existing api33 x64_86 which is way faster?
Short answer, no.
These are different instruction sets designed for different CPU hardware. armeabi is for Arm CPUs, and x64_86 is for (e.g.) Intel/AMD CPUs.
I've looked on shakebuild and it looks as though you have to have a haskell installation on a networked machine?
(verbiage to placate so follows)
Shake is a Haskell library for writing a build system. If you want to go for an air-gapped machine, you have three options:
If the build system won't change, you can compile a single static binary for your build system and ship it over to the machine. That's probably easiest. It will have no runtime dependencies.
If the build system changes a little bit, presumably it changes at a lower cadence than the code you are compiling. If so, just precompile the build system and ship it over with fresh code.
Finally, transfer enough stuff to the air gapped machine to build Haskell programs. If you are going that route, transferring enough to get the stack tool working is feasible - I've done it before. You are probably looking at several Gb of tools and libraries.
I have recently started Flutter development and on my machine, and the gradle build seemingly takes forever when completely restarting the app or running it for the first time, at times it gets quite frustrating. I am using an Ubuntu 20.04 (KDE Plasma env) with 8 GB RAM/ 240 GB SSD and using VS Code for running the app. Is there any way to optimize this? Would appreciate any suggestion on the same. Thanks in advance.
According to this documentation by developer.android.com there is a way to optimize gradle build by using JVM Garbage collector.
Add this parameter to your gradle.properties in your android folder you can find it on /{your-project}/android/:
org.gradle.jvmargs=-XX:+UseParallelGC
and if there are already value set in this field, just add a new option:
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC
I recently got a new Macbook Pro at work and noticed that building our codebase in Maven2 takes about 15 minutes while others on my team with slightly older Macbooks (but similar/same specs) build in about 5 minutes. After asking around, I've found one other person on my team whose builds take 15+ minutes. I'm talking about a fresh checkout of the code, with all of us on the same version of Maven (2.2.1) and Java version: 1.6.0_29, running 'mvn clean install' from the root of the project. Both of us with slow builds are on Lion (10.7.3), while the people with 5 minute builds are on Lion or Snow Leopard. My machine has 8GB RAM with 2.3 GHz i7, so it doesn't seem like that should be a problem. AFAIK, the machine came with Lion (versus upgraded from Snow Leopard) so I don't think it's that it was upgraded in place from Snow Leopard which it seems some people have had issues with. We with the slow builds both have 5400 RPM drives while most of the others have 7200 RPM drives, but alas, one of the other guys with the 5 minute builds has the exact same 5400 RPM drive as us ... so that sort of rules out that theory.
I've run a memory test (checked out fine), run disk verify and permissions repair in Disk Utility (fixed some permission issues, but didn't change build times), disabled swapping, made sure filevault was off, build from a different directory, all to no avail. A few interesting points which makes me suspect an OS issue:
I have a Ubuntu VM on said machine, and doing a 'mvn clean install' in there is even considerably faster than natively in OSX (10 minutes versus 15 minutes)! FYI, the native Ubuntu guys on our team also build around 5 minutes. And when I was running Ubuntu in a VM on my Windows box a few months ago, builds averaged 15-20 minutes.
Building the slowest component of our project by itself takes about 3-4 minutes normally. The interesting thing about this component is that there is very little code in it. In fact, all it is is one test case and 135 MB of resource files. Of the 3-4 minutes, I counted about 100+ seconds of it is sitting on "Copying 63 resources".
Running in OSX Safe Mode, building the aforementioned slowest component took only 42 seconds, of which about 7 seconds were spent on copying the 63 resources.
I'm not sure what else to try at this point, but I feel I'm so close to nailing it down. If it wasn't such a marked difference, I wouldn't worry about it so much, but 15 mins versus 5 mins is huge in my workflow. I don't feel real comfortable about giving my work computer to the Apple Genius guys, and our IT guy's not a Mac person. Reinstalling the OS seems to be the answer I've seen online, but that seems a bit excessive and intrusive. (I realize this is more of an OSX question than a Maven question, probably, but Maven's been my benchmark. I don't notice any other slowness, but it's hard to say without using others' computers)
Has anyone encountered something like this? Any ideas on what to try? Thanks
Run mvn -X ... command on your machine and on fast one and compare times from the log files what tasks/plugins take the most time. That should give you a starting point. The two slowest parts are file system scanning and network access for checking artifacts/dependencies/plugin updates.
The former can be improved by tuning disk access (e.g. cache or switching to the SSD).
The latter can be improved by adding Maven repository manager, such as Nexus or Artifactory that would cache and optimize access to all remote Maven repositories.
OS X 10.6.7, Xcode 3.2.6 (although 3.2.5 shows the same behavior), Mac Pro - 2 2.4 GHz Quad w/ 8GB of RAM.
We have several of these machines, all but one are running great. A normal clean/build takes about 5-7 minutes. On the "naughty" machine it takes about 30 minutes.
Before starting the build the machine has over 5 GB of RAM free, CPU utilization usage is practically zero. We can't see anything that would be eating up resources.
This is just a pretty simple iOS project (using gcc 4.2) - nothing out of the ordinary. Once we kick off the build the XIBs are compiled quickly. It isn't until we get into the 15th-16th implementation file (.m) that the build process slows to a crawl. At that point we still have tons of RAM available and there is very little CPU usage.
Any recommendations as to how we might track down the issue with this machine?
Thanks!
Are you building with the release or the debug configuration? Stripping binaries (release configuration) can be pretty time consuming during build times.