core data - Poor initial load performance with heightForRowAtIndexPath and UITableView scrollToBottom -

i have uitableview reads information coredata via proper mechanisms (using fetchedresultscontroller, etc). information either textual, or url local image load tableview.

data needs populated in table in bottom-up fashion (similar messaging app). targeting ios 8+, if use estimatedheightforrowatindexpath, terrible jerkiness on 3+ multi line labels , images. estimate seems way far off unless it's 1 line uilabel. hunch cell height being estimated in top down manner, such cell heights growing top of cell bottom of cell. means scrolling top bottom fine, bottom top not, since cell being resized "downward" dynamically scroll upward.

i using heightforrowatindexpath calculate cell heights. problem takes long time view load because cell heights calculated @ once. using cell height caching store cell height once view has loaded, scrolling buttery smooth.

so question this: how use heightforrowatindexpath without taking 3-5 second initial load hit?

and follow bonus question, there way reliably use estimatedheightforrowatindexpath when have cells vastly different in height? we're talking anywhere 44px 300px. i've read, can't use estimatedheight calculation @ in situation.

i've exhausted of stackoverflow posts concerning estimatedheight/heightforrowatindexpath , i'm starting @ same posts more once. i'm stuck.

why woncha stuff few rows in table populate visible area , after viewdidappear start stuffing older messages on top of table 1 or 2 @ time animation none, automatic or whatever. way postponement of uitableview population me thinks you'd passable performance.

or skype way, postponing population of table older messages until after table bounces off top edge.