Archive for the ‘Optimization’ Category

DateTime.Parse Performance Data

02/22/2012 Leave a comment

The potential performance pitfalls of DateTime.Parse are well discussed. What I don’t see as often: actual performance test data.

So, I’m contributing my own test data to the discussion. Read more…

Dangerous .NET CLR Quirk Lurks In Unfiltered Generic Methods

03/02/2011 3 comments

Step right up! Step right up! Come inside and watch in horror as our sample C# code compiles, runs, and spectacularly fails right before your unbelieving eyes.

Read more…

Part II: Spawning Threads Using Selectors With Multiple Parameters

05/18/2010 9 comments

In Part I, we introduced a method that emulates the Apple-supplied convenience method performSelectorInBackground:withObject:, but which adds support for selectors that take multiple objects as arguments. We saw the power of NSInvocation objects, but also saw how they were a bit cumbersome to use on a routine basis. Our solution gave us what we wanted by allowing us to pass in an array of objects to be used, along with a multi-parameter selector, to invoke an arbitrary method on a background thread (or on the main thread).

This solution is a great step forward when we need to invoke something like [myObj setCharacter:@"The Doctor" currentActor:@"Matt Smith"]. But what if we have a bunch of methods that don’t take objects? Wrapping them all in NSValues begins to really litter-up the code, and is frankly a bit tedious. And what if one want to invoke something like [myObj setCharacter:@"The Doctor" favoriteActors:@"Tom Baker", @"David Tennant", @"Matt Smith"]? There has to be a cleaner way, right? Behold! There is, and the answer lies in the somewhat obscure-ish va_arg macro. Now we can save the world from our unwieldy code. Allons-y!

Read more…

Mysterious CALayer Object Proliferation Caused By Core Animation?!

07/15/2009 Leave a comment

I have been reviewing some UI code that I just completed. It’s my regular practice to check for leaks, etc., so that I can verify that my code is doing what I think it’s doing. I typically fire up Instruments running the Leaks monitor, and not only review any leaks that are found, but also review Object Allocation behavior.

I plugged a couple of leaks that sprang up, but I still could not figure out why object allocations were growing to infinity (albeit at a snail’s pace). I could launch my app and just let it sit idle and CALayer objects were just proliferating. I narrowed the problem down to a simple background [UIView animation] block. Surely Core Animation didn’t leak, right?

Turns out, the answer is: not really. Thanks to Apple Devforum poster Rincewind, we now know:

You are probably seeing a bug in ObjectAlloc. You can confirm this in one of two ways

1) Examine the memory address of these “leaked” objects – they will probably all be the same (or a small set of addresses).

2) Add the Memory Monitor instrument from the library and watch your application’s Real Memory – this is generally a far better indicator of how much memory your application is using in total anyway.

Sure enough, he was right! The objects pouring into the list on Instruments all clustered around the same few memory addresses. Watching the physical memory confirmed that, despite the ever-growing heap in Object Allocations, physical memory was holding steady.

Whew! But Grrr! Hopefully you can avoid the frustration (until it’s patched).

Happy Debugging!