Vinay Chavan

We typically use one of the following text search predicates with costs in terms of performance,

• Beginwith, Endswith ($)

These are the cheapest queries that are possible in case of text  comparisons. In these cases first or last few characters are checked with the text and if the match is not found, code exits. 

• Equality ($)

We can consider this query as similar to that of Beginswith, which checks all the characters in text.

• Contains ($$)

This is bit more expensive as it keeps checking for a match in whole text length.

• Matches ($$$)

This is the most expensive query in case of text comparisons, system needs to go through and work with regular expressions engine.

• Case and Diacritic Insensitivity [cd] ($$$)

This is a lot more expensive query. Lets first see what does this do. Mentioning [cd] for contains query, treats a, A, à, á, â, ä, æ, ã, å, ā as simply ‘a’. By doing this we are commanding our system not to make difference between all these characters. System has to work a lot to this comparison.

• Solution is to use canocicalized Text Seach [n] ($$)

When people search for some text, they type few characters and expect results. What we really need to do here is to use canonicalized text property. To do so we need to separate out the text that will be searched and text that will be displayed. For this we need to convert a display text with diacritic characters into canonicalized text in lowercase. Following code does the magic of converting string into canonicalized string.

NSString *str = @"àä";
CFStringTransform ((CFMutableStringRef)str, NULL, kCFStringTransformStripCombiningMarks, FALSE);
NSString *searchText = [str lowercaseString];

kCFStringTransformStripCombiningMarks is the identifier of a transform to strip combining marks (accents or diacritics).

Once we have string that is normalized form of the display text, we can apply text comparison with [n] and pass canonicalized-normalized query text. This saves lot of clock cycles that are wasted in case of case-diacritic insensitive search.

• Fetch only what is required.

Your UI can not show all the data that exists in the table anyway. Don’t put extra pressure on core data to fetch data what you are not displaying on the screen. Every app has a different requirement for performance. You need to test the performance of your app by experimenting with batchSizes and fetching objects as faults.

If you are not going to update or read managedObject relations, try using NSDictionaryResultType for fetchRequest result type. Specify which properties needs to be fetched.

• Use attribute types smartly, don’t use string for all. Numerical operations are always way faster than string operations.

In case of Predicates, always specify numerical predicates before string related predicates. String comparisons eat up way too many clock cycles, numeric comparisons are very fast.

In case of string predicates Beginswith, Endwith are fastest and Contains, Matches are costliest operations. Matches use regular expressions to perform operations.

More about string search in coming post…

• Data duplication isn’t bad in case of relationships. It makes fetching faster.
• While creating to-many relationships, make relation Cascade and Nullify.

In case of Department(to-many)Employee relation, employee to department relation should be Nullify and department to employee relation should be Cascade depending on requirements. What Cascade does is automatically deletes associated employee objects when department object is deleted, Nullify doesn’t delete objects – It breaks the relation between objects and sets relation to nil.

• Turn ON indexing only for attributes used in searching, fetching.

Indexing increases insert and update time, larger the number of insertions or updates, more is the time taken for creating indexes.

• Make use of multiple ManagedObjectContexts using parent and child relation. (iOS5 onwards)

Parent ManagedObjectContext should be of Concurrency Type NSMainQueueConcurrencyType. This is supposed to be only used for MainThread UI activities. Chile ManagedObjectContext should be made NSPrivateQueueConcurrencyType. Make larger inserts and updates on this context in background and save child context followed by parent context save. Chile context save merges changes into master/parent context and final parent context save actually writes data to sqlite file.

• Best way to delete all data is to break the complete Core Data Stack.

To delete all the data, delete the sqlite file. Its much faster than traversing and deleting each object and its relationship.

• Use multiple ObjectModels and Sqlite files when required, Its not mandatory to use only one.

If you need to delete partial data (Upon logout or some similar action), its a good idea to physically separate data which needs to be deleted. Just delete the sqlite file when you need to.

• Put Core Data Stack code anywhere but not in App Delegate, keep it as a separate object itself if possible eg. VCCoreDataStack.
• See what is happening under the hood.

Pass following arguments on launch of the app,

-com.apple.CoreData.SQLDebug 1

Pass argument 1, 2 or 3. Depending on what all data you need to see.

Saw this amazing example of bad UX today, the directory of pantaloons shop! Its supposed to be a simple map of the floors.

why does ground floor is at the top and top floor at the bottom?

Directional arrow next to ground floor suggests that if you go down, you reach the first floor!

How can people mess up such a simple thing?

Upgraded my Mid 2009 MacBook Pro 15” to 8GB DDR3 RAM and 64GB OCZ Octane S2 drive…

Faced few issues initially, system wasn’t booting up from new SSD. Tried to downgrade EFI firmware from 1.7 to 1.6. It didn’t help much.

Then updated SSD firmware to latest using firmware tools… And know what, it just works! 

Currently running ML 10.8.3 with EFI Firmware 1.7 without any issues.

Here is the link that helped a lot… 

http://www.ocztechnologyforum.com/forum/showthread.php?104990-NEW!!-OCZ-Bootable-Toolbox-Mac-Edition

Really???

Whats bad with these apps?

1. Bad Types, not at all readable on the device. Specially Kings XI punjab app!
2. Almost none of the apps really do follow UI guidelines
3. F**ked up tab bars
4. F**ked up control alignments
5. Ok I understand about having brand colour apps but still like this??? Look at RCB app, I mean really? You really want me to install that shit on iPhone?