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"
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (Xcode-users@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
