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.
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 been searching this question for quite a while but still none of the solutions work, this time I got the error message, Xcode playgrounds don't work and if I make a regular iOS app project and run it in the simulator it will have the loading screen for around 15 minutes and then gives the error message: The operation couldn't be completed. (Match error -308 - (IPC/might) server died)
I've recently tried using my iPhone to run projects which works. Is there and way to make Xcode work normally.
I am using a Mid-2012 MacBook Pro Non-Retina with 4GB RAM.
I had similar errors (if overly slow apps are an error). Your problem is that one process awaits another and has an expire timeout. The other process takes a large time to load.
you might be able to solve this by adding a substantial amount of ram and moving the simulators to a RAM disk, alternately you might upgrade to an ssd.
realistically your best bet is buying new retina MacBook Pro. Thats how I solved it...
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?
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.
Not a long time ago I updated Xcode to version 4. This new version spent a lot of time on indexing the project (it's quite large). That's why I would like to disable indexing. Searching through Xcode help and internet gave no results.
Open a terminal window and paste this command:
defaults write com.apple.dt.XCode IDEIndexDisable 1
You'll lose some features (autocomplete, jump to definition, some of the assistants won't work right). But you'll gain back ram and cpu.
For my project Xcode went from using 2 Gigs to a few hundred MB. (which I sorely needed to compile with ;))
Reducing the priority of the XCode process helps:
renice 10 -p PID
You can get the PID from the Activity Monitor or top/ps commands.
This problem has been noticed on this newsgroup:
The crux of it seems to be that XCode4 uses crazy amounts of ram during indexing - like, 5gb or so(!), and thus if you're on a machine with something like 12gb, there's no problem, but if you're on a laptop with only 2gb or so, you'll have some pretty severe paging going on.
I'm guessing apple's internal engineers were all rocking maxed-out mac pros or something.
I ran into either the same problem or something similar. My project includes heavily templated C++. Including those headers in the PCH file solved the problem for me.
My new retina Macbook pro running XCode 4 was extremely slow doing indexing (and everything else). My Mac mini at home was very fast working on the same project!? Turns out it was my anti-virus software - doing a scan of every file read or written on the MacBook. Turning that off sped everything up by a ton.
Slow indexing is not a given. And more memory isn't necessarily better.
I have a medium sized project for work ~ 500 source files. After deleting the derived data, it takes 18 minutes to finish reindexing this project. That's with no other apps open and not doing anything else with the computer. This is on a fairly recent Macbook Pro with 8G of memory and an i7. Horrible, right?
My home machine is a recent Mac Mini with 4G of memory and an i5. On that machine the exact same project takes 40 seconds to completely index.
I don't yet know what the difference is, but I'm working on it.
It's not possible to disable indexing in Xcode 4. Many of the IDE's features are built on top of the index it maintains.