I spent some time today on improving performance in my iOS development project, and I came up with some results that may be of interest to others working with Core Data. Note that the hacks demonstrated below are based on Time Profiler measurements taken on my (egregiously unoptimized) app under development. The underlying “performance issue” only occurs when you’re using standard Core Data scalar accessors unusually frequently, like my app did. It is overwhelmingly likely that your application does not exhibit the same behavior; therefore, please use Instruments to verify that read accessors are actually slowing down your app before applying any of these tweaks.
My close personal friend and colleague Encsé posted a fun little programming exercise and invited us to send him solutions in our favorite Turing-complete tool, especially if it happens to be mod_rewrite or C++ templates. Unfortunately, I don’t think there is a single sane person on the planet who would consider C++ their favorite anything, and I like Encsé better than to let him needlessly associate with any additional crazy people. Obviously, this meant that I had to delve into the murky depths of template madness myself.
Here is a copy of the problem, in case Encsé decides to delete his post once he finds out it has been tainted with C++ — which would be an entirely sensible (and, indeed, healthy) reaction:
Find a number consisting of 9 digits in which each of the digits from 1 to 9 appears only once. This number must also satisfy these divisibility requirements:
- The number should be divisible by 9.
- If the rightmost digit is removed, the remaining number should be divisible by 8.
- If the rightmost digit of the new number is removed, the remaining number should be divisible by 7.
- And so on, until there’s only one digit (which will necessarily be divisible by 1).
OK, so I implemented a solution using C++ template metaprogramming. It was actually easier than I thought, and the experience was surprisingly interesting. Which is not to say I’d like to do it again. I imagine I would feel this exact same way after performing an autopsy.
Just a few years ago, Palm OS had a large user base and an active third-party developer community, with tens of thousands of apps available from multiple, open application stores, most prominently PalmGear.com. The OS was used on small mobile devices from PDAs and GPS systems to fancy smartphones — it was a nice system that was cutting edge in the nineties, but by 2004, it has become horribly outdated. PalmSource’s efforts to introduce OS 6 — a version with a modern, 32-bit, multitasking, memory protecting architecture — proved futile: no Palm OS 6-based device was ever produced. By 2006, Palm has mostly switched to producing Windows Mobile phones. Then in 2007 the iPhone happened, and its brilliant user experience and centralized, integrated App Store instantly made all Palm OS devices still on the market obsolete.
All this means that in 2010 it may seem a tiny bit too late to publish Palm OS source code. Thankfully the system still has a small group of enthusiastic users who work on keeping the platform alive. To this very day, I’m still regularly contacted about my old Bluetooth remote control application, which I sadly didn’t keep updated to run on the last few generations of devices. It’s great that people care about my work, and the least I can do is to let them take control.
Néhány szavasnál hosszabb magyar szöveget gépelni iPhone-on pokolian nehéz dolog, mert az ékezetes betűket nem lehet közvetlenül bepötyögni. Az alapbetűt nyomva tartva a kb. fél másodperc szünet után felugró menüből ki tudjuk választani a kívánt ékezetes változatot, de ez nagyon megszakítja a gépelés lendületét. A magyar nyelvben az ékezetes betűk gyakorisága kb. 11.383% — ez alig marad el a leggyakoribb E betű 12.256%-ától. Átlagban minden nyolcadik-kilencedik betűt tehát csak ilyen nyakatekert, lassú módszerrel tudjuk begépelni, ami a gyakorlatban ahhoz vezet, hogy inkább nem is használunk ékezeteket.
My stupid little six years old idea is now a Logitech product on the iPhone.
My original implementation on ancient Palm PDAs/smartphones emulated a standard Bluetooth peripheral and it did not need special software running on the computer — similar apps on the iPhone work over WiFi and require starting up special server programs. This is to be expected, since Palm supported third-party applications accessing the Bluetooth radio (they even provided a reasonably convenient & full-featured API for it), while Apple does not. This is, at the end, a good thing: there is a limit to what an Apple-blessed app can do to an iPhone. Buggy Palm applications could and did frequently crash the device. There was a proliferation of third-party hacks that hooked into system internals and changed essential system behaviour, invariably destabilizing it. The Treo was a great toy, but a horrible phone — I had to reset it multiple times per day and learned not to rely on it for anything important. I can’t even remember when I last rebooted my iPhone.
The royalty checks I received for BlueRemote over all these years have paid back the price of the development kit (i.e., my Tungsten T2 and Treo 650), with perhaps just a little extra. I believe this was considered a success back then, considering that I did not do any marketing whatsoever. BlueRemote’s price was $14, with (AFAICR) 60% going to Motricity’s pockets. For contrast, the going price for similar software in the App Store is 1$, with 70% going to the developer. (The Logitech app is for promoting their hardware, so it’s free.) The fact that it still seems worthwhile for one-man teams to produce software for 0.7$ a pop is a testament to the App Store’s success.
Once in a while, I still get an email complaining that BlueRemote does not work on the lastest generation of Palm OS devices, with their fancy new Bluetooth chips. It would be mildly amusing to fix this at some point and release an update.