…but Geek decided to skip 12th grade and go to Reed College next year! That sudden acceleration of him ending high school and starting college has caused a lot of scurrying around as we figure out logistics. We currently plan on selling our 21 acre homestead and farm and moving into Portland near Reed so Geek can live at home the first year (he’s only 16). As a result, we’ve been too busy to do much here on the blog.
We’ll be back!
Rich @siegel asked on twitter:
How expensive is it to call a block, versus a method, versus a function? Asking for a friend.
— Rich Siegel (@siegel) March 14, 2013
and @danielpunkass pointed to a @mikeash blog post with some tests:
@rentzsch @siegel I was reminded by @mikeash of this old gem: mikeash.com/pyblog/perform… Maybe just needs an update for blocks…
— Daniel Jalkut (@danielpunkass) March 14, 2013
I was curious about this so I added that test and a test of the new @autoreleasepool {} construct. The modified code is here (@mikeash feel free to grab it and use it on your site) and the results of running this on my older MacBook Air 1.8GHz Core i7 with 4GB 1333MHz DDR3 RAM and SSD (other apps running in the background) are as follows:
| Name | Iterations | Total time (sec) | Time per (ns) |
| IMP-cached message send | 1000000000 | 0.2 | 0.2 |
| C++ virtual method call | 1000000000 | 0.4 | 0.4 |
| Block invocation | 1000000000 | 0.5 | 0.5 |
| Integer division | 1000000000 | 2.3 | 2.3 |
| Objective-C message send | 1000000000 | 2.7 | 2.7 |
| 16 byte memcpy | 100000000 | 0.4 | 4.4 |
| Floating-point division | 100000000 | 0.6 | 6.0 |
| Float division with int conversion | 100000000 | 0.6 | 6.3 |
| New Autorelease construct | 10000000 | 0.2 | 17.1 |
| NSAutoreleasePool alloc/init/release | 10000000 | 0.6 | 63.5 |
| 16 byte malloc/free | 100000000 | 6.5 | 64.7 |
| NSInvocation message send | 10000000 | 0.9 | 91.3 |
| NSObject alloc/init/release | 10000000 | 1.6 | 165.0 |
| 16MB malloc/free | 100000 | 0.1 | 880.0 |
| NSButtonCell creation | 1000000 | 3.2 | 3201.7 |
| Read 16-byte file | 100000 | 0.8 | 8250.8 |
| pthread create/join | 10000 | 0.2 | 23009.4 |
| Zero-second delayed perform | 100000 | 2.8 | 28038.3 |
| NSButtonCell draw | 100000 | 4.7 | 47448.6 |
| 1MB memcpy | 10000 | 0.8 | 78902.2 |
| Write 16-byte file | 10000 | 2.1 | 209280.7 |
| Write 16-byte file (atomic) | 10000 | 3.9 | 392459.6 |
| Read 16MB file | 100 | 0.8 | 8050127.5 |
| NSTask process spawn | 1000 | 67.3 | 67305116.9 |
| Write 16MB file (atomic) | 30 | 2.1 | 70342873.5 |
| Write 16MB file | 30 | 2.2 | 72666382.1 |
Built it with:
cc -v -lstdc++ -framework Cocoa perf.mm
and the dev tools are:
Apple LLVM version 4.2 (clang-425.0.24) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
Xcode 4.6 basically.
If Mike reads this: feel free to grab any of this you want and copy it to your site. Just put it here because that was easiest.
Not sure my tests are exactly right so feel free to make suggestions etc. One thing I didn’t test but might add another test for is how handling local variables used in the block impacts things; likewise local __block variables in the block, but the whole point of this test suite seemed to be keeping things as simple as possible so I stuck with that.
UPDATE:
@schwa asked about iOS and since I had the day off I went ahead and did those as well, though I had to remove some tests I didn’t feel like fixing for iOS (zero delay perform selector messes with the RunLoop which caused crashes, no NSButton class, NSTask (?), and the file I/O tests weren’t going to work as is). Started with the single view iOS Application Xcode template and added a text view to jam the results into. This was run on an iPhone 5 running iOS 6.0.2:
| Name | Iterations | Total time (sec) | Time per (ns) |
| C++ virtual method call | 1000000000 | 0.8 | 0.8 |
| Block invocation | 1000000000 | 2.8 | 2.8 |
| IMP-cached message send | 1000000000 | 4.6 | 4.6 |
| Objective-C message send | 1000000000 | 14.7 | 14.7 |
| Float division with int conversion | 100000000 | 1.8 | 17.8 |
| Floating-point division | 100000000 | 1.8 | 17.8 |
| Integer division | 1000000000 | 21.6 | 21.6 |
| 16 byte memcpy | 100000000 | 6.1 | 61.0 |
| New Autorelease construct | 10000000 | 0.8 | 83.4 |
| 16 byte malloc/free | 100000000 | 46.8 | 467.5 |
| NSAutoreleasePool alloc/init/release | 10000000 | 5.2 | 519.2 |
| NSObject alloc/init/release | 10000000 | 12.6 | 1259.0 |
| NSInvocation message send | 10000000 | 13.5 | 1346.3 |
| 16MB malloc/free | 100000 | 1.5 | 15374.9 |
| pthread create/join | 10000 | 1.2 | 116415.9 |
| 1MB memcpy | 10000 | 3.9 | 394341.5 |
Humans generally hate to wait. So as software developers we try to make everything as fast as possible. Sometimes things just take time. Like when you have to do 38,000 of something moderately slow.
Finite progress reporting (by which I mean “X of Y” or “X%”) is generally better than indeterminate reporting (a spinner which shows only that something is happening, if just the spinner spinning) from a user’s perspective.
Experienced programmers will have analyzed the performance on their application and realized that in some cases the updating of the progress count UI is actually taking a significant percentage of the total time to do the operation. The usual “fix” is to only update the count after processing a chunk of items – say 10, 50, or 100 items – instead of after each one. This amortizes the cost of updating the screen across more than one item and reduces the total number of updates which thus makes updating the UI a smaller percentage of the total time for the operation. I often see people use round numbers like 10, 50 or 100 in a modulo test like this:
if (done % 100 == 0 )
{
[self updateProgressDone: done of: total];
}
Here’s the thing I just noticed: as a user it doesn’t feel as fast or good to see something count up by hundreds, or even fifties. I decided that it was because so many of the digits aren’t changing for such large percentage of the time I watched. So I tried changing the modulo to 99 so that all the digits change and sure enough: it feels faster. Fascinating!
I then tried something else that I kind of like too: take the performance hit on the last few and display them all at the end like this:
if (done % 99 == 0 || done + 100 > total )
{
[self updateProgressDone: done of: total];
}
So the UI will visually count up by 99 at a time until the last 100 and then it’ll count up by ones. If that’s too slow you could count by fives at the end like this:
if (done % 99 == 0 || (done + 100 > total && done % 5 == 0) )
{
[self updateProgressDone: done of: total];
}
Anyway, something I was playing with today. I’m sure there’s a lot more interesting psychology involved with this (I remember reading about a progress bar that speeds up it’s reporting over time), but this is an interesting simple change that really made a difference in some UI I just wrote. I’d love to do actual research on this but alas I have software to write and ship 
2013.03.17 UPDATE:
So after using this on various machines with varying other loads on the machine I decided that anything which isn’t time based is doomed to failure because what matters is how often the user perceives an update of status happening. So I’ve switched to the following:
static dispatch_time_t lastUpdate = 0;
dispatch_time_t now = dispatch_time( DISPATCH_TIME_NOW, 0);
if ( now - lastUpdate > 250 * NSEC_PER_MSEC )
{
lastUpdate = now;
[self updateProgressDone: done of: total];
}
and am updating every quarter second (250ms). I may play with putting the ramping up of updates in there (starting with say 350ms and going to 200ms towards the end, or something like that), but this actually seems good enough now and handles the case where the app is running on a slow machine and spotlight is dogging the entire machine etc.
Just ran across a tweet about code.com which not only has some interesting learning tools on it, it has a great list of references for learning and teaching programming. In particular the Code Academy page.
I’ve been asked by parents a number of times how I taught Geek to program so young and what they could do to help their kid learn to code. This seems like a good place to start. Geek started with StageCast and then Scratch and then moved on to Python. I’m not sure what StageCast looks like any more (that was a long time ago for Geek), but all worth checking out.
So I have an old iPod Photo (color) 60GB iPod that’s been working great for a long time now (since July 2005!) that I use for my office music while I work. I’ve just now finally run out of space on it and so I thought I’d use iTunes’ “Convert higher bit rate songs to…” feature to cram my growing collection onto the existing iPod. I’m on an iMac running 10.7.5 and I was connecting via a USB cable.
Nice idea but it always fails after few hundred songs when I try to sync with this setting turned on. Grrrr.
Tried turning off “Enable disk use” because there was always an error about the disk being unmounted improperly when it fails. No dice.
Finally thought that maybe it was a USB issue and so tried connecting it via Firewire (which this older iPod Photo can do) and Bingo! It seems to be working (4860 songs of 7839 copied so far without a problem).
Thought I’d write this down here so others could find it. I should file a radar but I’m having trouble imaging Apple caring about this old device… Could be an underlying USB issue though…? Anyway.
I was playing with three-point perspective (see Wikipedia), and decided to make this quick test piece of a city of towers, and post it here for people to see. Enjoy!
Geek just asked me:
“Can you do a ‘List Comprehension’ in Objective-C like you can in Python?”
First I had to ask him what the heck a “List Comprehension” was and he replied:
“listOfSquares = [x*x for x in listOfInts]“
ah, ok!
Seemed like it should be easy in ObjectiveC, but it takes a bit more code than in python!
Here’s my simple example for him:
// initialize a start array (a) and a destination array (b)
NSMutableArray * a = [NSMutableArray arrayWithObjects: @"Hello", @"Will This work?", @"can it work?", @"Yes!", nil];
NSMutableArray * b = [NSMutableArray arrayWithCapacity: [a count]];
NSLog(@"start array: %@", a );
// here's a simple List Comprehension (uppercase all the strings)
[a enumerateObjectsUsingBlock: ^(id obj, NSUInteger idx, BOOL *stop) {
[b addObject: [obj uppercaseString]];
}];
NSLog( @"ending array: %@", b );
Here’s the output:
2013-02-04 21:01:26.156 test[45743:403] start array: (
Hello,
"Will This work?",
"can it work?",
"Yes!"
)
2013-02-04 21:01:26.157 test[45743:403] ending array: (
HELLO,
"WILL THIS WORK?",
"CAN IT WORK?",
"YES!"
)
Update: Several people have pointed out on twitter that this is more like a map() operation in python but also some noted that List Comprehension is a a form of mapping but one with a compact syntax. In any case this was mostly about Geek having a way he did things in python and wondering what the closest equivalent was in ObjC. This is at least one approach.
Update2: And as xinsight points out, while Geek asked if there was a way to do this with blocks, the “old fashioned way” is in many respects much cleaner:
for ( id obj in a ) [b addObject: [obj uppercaseString]];
Just learned this useful Xcode tip (works in Xcode 4.4+ I believe but I’m on Xcode 4.5.2):
If you shift+right-click on a view (or control+shift+left-click to simulate a shift+right-click) you will get a popup of all the views under the click and can choose any of them (to edit properties or what not).
This is especially useful with complex view hierarchies with multiple layers of nested views.
Here’s a screenshot showing you what it looks like. I shift+Right-clicked on a NSTableCellView embedded inside an NSTableView in an NSSplitView in a root NSView in an NSWindow. Navigating through the outline hierarchy would be slow but this is very quick.
On a cold snowy day in Corbett…
Me: walking by cat on way to the house for lunch…
Cat: “Meow. Meow, Meow. Meow! MEOW!”
Me: “What?”
Cat: “Brrrr. Inside cat?”
Me: “no”
Cat: “29 degrees!”
Me: “Fur!”
Cat: “SNOW + 29 degrees!”
Me: “5x pissing on bed == OUTSIDE CAT!”
Cat: “Surgery! Ow!”
Me: “Let you back in 2 years later & you beeline for a bed. No!”
Cat: “meanie…”
Me: walks away to write guilty blog post
So the kickstarter that would have funded continued development of the game 1879 for which Geek & Dad was writing the iPad/computer version has been canceled by FASA due to lack of interest (or inability to get the word out, hard to know):
KS Cancellation and Thank You
Our project of 1879 iPad App, RPG, miniature game and figures has been live for over a week now. Based on the number of project backers, pledges and trends it looks like meeting our goal will be very challenging. Considering all of the factors, we have decided to suspend our project as described.
First of all I would like to thank all of you who backed our project. Your commitment is what Kickstarter is all about.
We had hoped that the combination of miniatures, RPG and software would appeal to a large number of backers. Unfortunately, this has not been the case. So while work on the core miniatures game and rpg will continue, albeit at a slower pace, work on the iPad application will be halted.
Look for a revamped Kickstarter project early in the New Year. This streamlined project, focused on the new 1879 game system and miniatures, will hopefully be more successful.
To all those who backed this project, once again thank you.
Thank you,
Ross Babcock
That means we’ll be stepping back and figuring out what to do next. Geek has 11th grade in high school to finish, a part in a local seasonal performance, track team and working towards his 2nd degree black belt in Tae Kwon Do in spring, and running lights and/or sound for the local children’s theater’s winter production, so I think he’ll avoid getting bored (!).
As the Dad, on the other hand, I will be footloose and fancy-free! Well…, not exactly – those pesky bills keep showing up so I imagine I’ll have to find some paying work to fend them off! I’m actually looking forward to diving back into iOS and OS X native coding – I’ve missed Objective C, Xcode, and the Cocoa frameworks quite a bit while we’ve been in Unity3d using JavaScript, C# and .Net. I have a copy of @bdudney’s iOS 6 SDK book (which looks quite good for intro/intermediate programmers so far), and have also been asked to review another upcoming iOS 6 book by the publisher. So between those I ought to be getting up to speed on iOS 6 quite quickly!
Of course Geek is dreaming up game ideas a-mile-a-minute and some of them sound pretty cool! So we might just have to spend winter break building a prototype of one (or more!) of those… Sounds like fun!
In any case, thanks to those of you who helped spread the word about the kickstarter project and who have offered your friendship, encouragement, and advice as we learned Unity3d and built the prototype. We had a great summer and learned a ton.
Onward!
- Dad
