KDBDallas

Recently I was doing some performance stress testing on my upcoming iPhone app, Newsprint, and ran into a little Core Data gotcha that I thought I would document for both myself and for Google to index for others.

Special thanks to Jeff LaMarche for guiding me in the right direction to figure this out. You can find his blog at: http://iphonedevelopment.blogspot.com/

This issue came to play when I needed to do a fetch request from Core Data and then run a couple of Predicate “searches”/”filtering” on the data.

My original thought was that doing a single fetch request and then running my different predicates on the returned set of objects would have better performance then doing multiple fetch requests since I would only have to pull from the Core Data SQLite DB once and then I would have everything in memory and I could just simply manipulate it.

Turns out that this is HIGHLY incorrect.

If instead you just do multiple fetch requests and implement your predicate into your fetch request, that Core Data and SQLite are smart enough to scan the records more efficiently and without causing Core Data Faults to fire.

This gives a MASSIVE speed increase!

So if you are ever doing something similar, make sure to check this method and see if it to can speed your app up.

I have been finalizing the beta for iDeskCal 2.0 and in the process came across ChocTop.

ChocTop is a system for rapid mac software DMG packaging.

In setting it up and using it I found that it lacked a feature I wanted.
Mainly the ability to specify that it should you a Debug build instead of the standard Release build that you would usually use.
The reason for wanting a Debug build is simple… I am packaging up a Beta.

So even though I don’t know Ruby (which is what ChocTop is written in) I set foot to add this feature.
Luckily like most computer languages I was able to understand it enough to understand what was going on and enough to add this new ability.

Once I was done and used it myself, I sent it back into the developer and he has already integrated it into the repo version of the code.

If you are a Mac developer checkout http://drnic.github.com/choctop/

I have recently been debugging some Objective-C and Cocoa/Cocoa Touch code.

Not being familiar with all the code and with a TON of methods being accessed in milliseconds, my attempts at stepping through the code just wasn’t working, as clicking ‘Step Into’ as fast as I could keep up and over an hour of stepping through I was still not even close to figuring out what I needed to know.

This lead me to the thought of logging every method that was accessed and then I could step look through it and skip around as needed.
However with 60 some odd files and say maybe 20 methods in each file, that would take a lot of NSLog’s.
I started looking around and was pointed to bbums blog about doing something similar.
However it still would take adding some code, plus I couldn’t get it working right with the iPhone.

This lead me to wonder about DTrace.
After a recent podcast from Scotty at the Mac Developer Network, featuring Colin Wheeler talking about DTrace, I have been very interested in learning more about DTrace.

The difficult thing I have been finding is that since DTrace was originally written for Sun, it is hard to find info related to MacOS and more so Cocoa.

I then found a video from Colin about using DTrace with Cocoa and XCode.
http://www.viddler.com/explore/Machx/videos/8

I wasn’t able to get what I wanted working, so I hit Colin up on Twitter and then talked to him a bit in email and he pointed me to the Golden Solution!

The solution is:
objc$target:::entry{}

So I took that and created a DTrace script.
You can grab it here:
http://kdbdallas.com/wp-content/uploads/2009/02/logallmethodsd.zip

To run it open Terminal and run:
sudo ./logAllMethods.d -p PID

Of course replacing ‘PID’ with the PID of your running program and remembering that for DTrace ’sudo’ is required.

Also note that this works for iPhone programs running in the iPhone Simulator.
Just look for the PID of your iPhone app within Activity Monitor once it’s running in the simulator.

Be careful as depending on the program it can spit out a TON of data VERY quickly.

Running this against Adium for only a fraction of a second gave me a couple hundred lines of output.

The output looks like this:

tesseract:Desktop dallas$ sudo ./logAllMethods.d -p 4371
dtrace: script ‘./logAllMethods.d’ matched 71222 probes
CPU ID FUNCTION:NAME
0 59398 -retain:entry
0 34684 +retain:entry
0 32061 +idleAllMovies::entry
0 32062 -idle:entry
0 34707 -retain:entry
0 32914 -_usingVisualContext:entry
0 32878 -_resyncNaturalSize:entry
0 31935 -loadState:entry
0 31972 -naturalSize:entry

Hopefully this helps someone out there.
Just remember always use the info I post for good.
(or if its for evil make sure it profitable and then send me a cut)

Once again, special thanks to Colin Wheeler.

If you have ever wanted to use a Indeterminate Spinner NSProgressIndicator on a dark background you have probably been upset to find that there is no way to get a white spinner.
That is where WhiteIntermProgIndicator comes into play.
WhiteIntermProgIndicator, is based off of AMIndeterminateProgressIndicatorCell by Andreas at Harmless Cocoa.

Screenshot:

Download: WhiteIntermProgIndicator.zip

I am proud to introduce NSCoder Night for Phoenix.

If you haven’t heard of NSCoder Night, here is a brief intro (partially borrowed from the website)

NSCoder Night is a weekly event where Cocoa developers come together for some coding and camaraderie in the relaxed atmosphere of a coffee shop or pub with a wireless network.
Unlike more formal meetings like CocoaHeads there is no presentation, just hanging out with other (similar interest) geeks and working on your own projects or group projects. It is a great way to gain a IRL (in real life) friendship with other developers, as well as getting help on something you are stuck on.

It is kind of similar to how we go somewhere after XCodePhoenix meetings, but with your laptops and more frequently.

As there is no presentation it is a low key come and leave as you need type of meet-up.
If you can’t make it one week, thats ok, make it the next week.

The Phoenix chapter of NSCoder Night will be meeting Tuesdays at 7pm at Coffee Rush @ Gilbert and Baseline in Gilbert.

Fell free to to tell all your dev friends and we hope to see you there.

In Mac OS X 10.5 Apple added a new set of API’s for adding an application to the users login items in Cocoa.

In looking for the way to use this new API, I stumbled upon Justin Williams’ blog carpeaqua.com where Justin was nice enough to put together a code example project showing just how to use this new API.

You can grab the sample project at his public code repository http://secondgear-public.googlecode.com/svn/trunk/SGLaunchAtLogin/

Thanks again to Justin for making this available.

Hopefully this page helps with his Google position for people searching for this info.

Read his full post at: http://log.carpeaqua.com/post/27727810/adding-an-application-to-login-items-in-mac-os-x