| So, after the glow of joy that I am feeling from the Xcode team mostly fixing my, "stop animating everything" bug and the fact that I've been pretty much working 7 days a week for the past n+1 months, I decided to look into some funness related to Xcode before I need to wake up at 3 AM for a lovely Saturday stretch.
For giggles, I wanted to check out how Ludicrous Throughout affected my app's build time on my latest 1 year old laptop.
First of all, I created a RAM drive by conspiring great evil and entering this terminal command
diskutil erasevolume HFS+ \"RAM Disk\" `hdiutil attach -nomount ram://4194304`
Don't enter this at all until you have checked the diskutil man file and have proven that I'm not trying to erase your HD.
Now that you're proven that, this creates a roughly 2 GB RAM drive.
Running the AJA sped test app, this gave a R/W throughput of 3457.3 MB/s / 3503.4 MB/s throughput.
Meh. It's not AppleTalk throughput, but it will have to do.
Already underwhelmed, I copied my iOS project that builds it's own app, then links to source and builds about 3 linked libs, onto the RAM Drive.
I had to wait for a whole blink of my eyelids to complete before this completed. Pained sigh.
Next, I set the build location in prefs to be set to legacy. This makes the build folder(s) within the project's folders, but doesn't touch the derived date location.
Command Shift K.
Command B.
A build that normally takes 2 mins and 35 seconds of our iOS project took 31 seconds.
Sigh. Pained sigh. ONLY 5 times faster?
This will never do.
By moving the system and Xcode and the user folder onto a large enough RAM drive and gotten stupid faster builds where it takes more time to launch the simulator than it does to compile from clean.
Why this matters to me - as an experiment, if nothing more, is that we are rapidly getting to the point where we have an expanding matrix of builds to fire off on an automated basis. Each multiple of 5 in speed that we save is 5 x more processing bandwidth we have. That and the fact that Mac TrashCan Pros are religiously opposed to > 1 socket, this limits our access to the 24 virtual cores (12 real) that I used to enjoy.
Just a fun little diversion from "why doesn't this work?"
Here's my CrappleScript which wraps a shell script that I keep handy to make RAM drives if you feel so inclined for a taste of ludicrous speed.
on run {}
Start()
end run
on Start()
set myBlocks to 2097152 -- 1 GB in blocks set myGigs to 6
set myResult to display dialog "Desired size in GB for your RAM Disk:" default answer myGigs set myGigs to the text returned of myResult -- as string set myBytes to myBlocks * myGigs set myShellScript to "diskutil erasevolume HFS+ \"RAM Disk\" `hdiutil attach -nomount ram://" & myBytes & "`"
do shell script myShellScript end Start
And the output:
tell application "Script Editor" display dialog "Desired size in GB for your RAM Disk:" default answer 6 --> {button returned:"OK", text returned:"2"} end tell tell current application do shell script "diskutil erasevolume HFS+ \"RAM Disk\" `hdiutil attach -nomount ram://4194304`" --> "Started erase on disk5 Unmounting disk Erasing Initialized /dev/rdisk5 as a 2 GB case-insensitive HFS Plus volume Mounting disk Finished erase on disk5 RAM Disk" end tell Result: "Started erase on disk5 Unmounting disk Erasing Initialized /dev/rdisk5 as a 2 GB case-insensitive HFS Plus volume Mounting disk Finished erase on disk5 RAM Disk"
|