Restarted the Old CryptoQuip Solver

xcode.jpg

This morning, my old friend Bret poked me with a stick to get me moving, and I fired up Xcode 6.1 and loaded up my old CryptoQuip solver, and gave it a run. The results brought a smile to my face - again:

  2014-11-10 08:43:42.536 CryptoQuip[87664:8603115] Solving puzzle: 'Fict O
       ncc bivteclnbklzn O lcpji ukl pt vzglcddp' where t=n
  2014-11-10 08:43:42.572 CryptoQuip[87664:8603115] Solution found: 'When I
       see thunderstorms I reach for an umbrella'

and the total run was only 36 msec. Very nice!

Then I decided to convert it to ARC because I know iOS requires ARC, and it should be even faster - right? I mean it's not doing the retain and release, so it should be even faster!

So I converted it to ARC, and removed all the retain and release and autorelease, and rebuilt it and re-ran it:

  2014-11-10 12:30:32.582 CryptoQuip[89789:8710573] Solving puzzle: 'Fict O
       ncc bivteclnbklzn O lcpji ukl pt vzglcddp' where t=n
  2014-11-10 12:30:32.640 CryptoQuip[89789:8710573] Solution found: 'When I
       see thunderstorms I reach for an umbrella'

So with ARC, it's taking 58 msec - that's a real increase. I had to run it several times to make sure that I was really measuring it properly. But there it was... as plain as day - 58 msec. Wow. ARC isn't cheap.

And as I started to think about it, it made sense - at least I came up with a plausible explanation: What if the retain/release version was using the standard Autorelease Pool. Then it wouldn't really hassle with deallocation in the runtime - it'd wait until the work was done to run the collector. However, ARC would see what needed to be done and then do it as it wouldn't wait for the pool to clean up. In that case, all the creation and destruction would come at a cost: Time.

In the end, it doesn't really matter - we have to use ARC for iOS, and it's not horrible for performance, but it does mean that I'm going to want to be careful as we move forward with this to not create all the temporary objects.