I\'ve read up on \"static\" on several occasions, including just before posting this question. I\'m still searching for an \"Aha\" though.
In the context of UITableView\
My guess is that by declaring the string as static, that every time it gets passed into -dequeueReusableCellWithIdentifier:CellIdentifierforIndexPath:
that the same pointer is used each time (as statically declared variables are allocated only once on the heap, very early in a program's execution)
[NSString -isEqualToString:]
is most likely implemented to perform a pointer compare first, followed by a character-wise compare as the fallback, which I supposed could shave off a few cycles on each iteration.
There's not much to gain from this, as (a) table cell re-population operates on a typically very small set of cells, and is well optimized, and (b) table refresh is bursty -- it happens once and then doesn't happen again until the user scrolls or application logic changes up the content -- if you end up calling -reloadTable
100 times a second, then there's clearly something wrong with your application logic.
I suspect the static keyword is a vestigial legacy convention -- maybe back in the day, Apple hashed on the pointer, rather than performing a proper string compare.