[問題] 有關UITableView與Sqlite效能問題...

[chengreg (想重回校園的工程師)]

各位前備好:

小弟也如同各位前輩一同喜好開發iPhone程式,如今小弟在效能中有一問
請教各位前輩,也請前輩給予建議與指導,謝謝~~

狀況:
小弟有一Sqlite資料庫,此資料庫為之龐大,約有18萬筆資料於一Table表內
而小的設計一查詢界面撈取此Table表資料,平均約30~40sec完成
而完成的定義是顯示與UITableView內.

30~40sec是個很大的問題,因為iPhone4就是這個速度,那iPhone3GS or iPad1
的速度將會是個頭大的問題,因為使用者會以為當機拉!!!T_T

小弟開始分段取出每個時耗,想要抓出真正好時的地方是哪裡?
一開始以為是Sqlite Query DB時最久,但是發現
當小的Sql語法執行時,過程相當短暫(about 1sec~2sec)
重點在于,當執行完語法後,要將FMResult,用While回圈寫入NSDictionary
時,這個回圈的時間太久,(小弟需要計算每個UITableCell高度)造成30-40sec
的時間.....

左思右想,雖然知道原因,卻沒有任何方向去提升效能...

然而,小弟看了一下相同狀況於Android上卻出奇的快
原因是Android直接binding資料庫的DataSet...
我想這就是兩者的差別了...

以上狀況,不知是否有類似經驗的前輩給予經驗指導,與分享心得
請各位前輩不另惜分享....

再度謝謝^^

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 219.71.36.222
推 DLMC:不確定你現在還有沒有時間，或有精力去修改，
→ DLMC:但是如果改用CoreData在效能及程式碼的管理上，
→ DLMC:會有很大的改善。
推 DLMC:CoreData Programming Guide有兩段可以參考一下：
→ DLMC:http://ppt.cc/zkuY  http://ppt.cc/G4FX
→ chengreg:喔?謝謝D大,因為都用Sqlite所以沒去瞭解過coerData
→ chengreg:小弟去試試看
→ kusowan:我想直接放到UITable不是個好的選擇
推 DLMC:同意kusowan大，如果在UITableView delegate處理資料，
→ DLMC:會重重影響到效能。
→ chengreg:不太明瞭K大的意思,K大是指將Result放到UITable?還是?
推 Adonisy:處理這麼大量的資料，本來就不建議啊...
推 popcorny:你是要把18萬資料都放進UITableView. 還是只有查詢出部分
→ popcorny:再把部分資料放進UITablewView?
→ popcorny:有建index..且只查出部分資料應該是花不到多少啊..
→ chengreg:回P大:是撈取後於UITableView呈現資料,但是While回圈造成
→ chengreg:時耗,Query DB沒有耗時多少時間
推 popcorny:既然跟query db沒關..那標題就不應該扯到sqlite囉..
→ popcorny:你把你的tableView:heightForRowAtIndexPath:這邊貼出來
→ chengreg:回P大,還是跟Sqlite有關,問題在FMResultSet讀取每筆資料
→ chengreg:需要用到While回圈把資料寫入NSDictionary內,這個時間
→ chengreg:消耗最久,所以還沒將資料放到UITableView上就要耗時約40s
推 popcorny:請問FMResultSet裡面有幾筆? 如果超過100筆
→ popcorny:可否用limit來限制query出來的數量?
→ popcorny:還有是否可以只select出需要呈現的column..而不要用
→ popcorny:select *這種把所有資料都撈出來的行為
→ chengreg:回P大,當然,小弟一定不敢用select *這種可怕的東西,但由
→ chengreg:於PM要求不可以分頁顯示(下拉10筆)的方式,所以必然先撈出
→ chengreg:來,Ｔ＿＿Ｔ
推 popcorny:即使PM要求不要分頁顯示..但是實作上還是可以模擬這種
→ popcorny:行為..這種我們稱為infinite scroll.. 簡單講,就是捲到
→ popcorny:boundary..這再透過limit,offset去query下個window的data
→ chengreg:回p大:恩~~小弟也是這樣想,架構要大改 T_T 謝謝P大
推 aecho:如果問題是在db上，那CoreData不見得會比較快…
推 aecho:http://goo.gl/XOLtH
→ aecho:上面這篇連結的作者，最後從CoreData改回用FMDB
→ aecho:就為了解決CoreData造成的效能問題。