2012-08-01 47 views
8

在我的應用程序中調用ORMLite RuntimeExceptionDaocreateOrUpdate(...)方法非常緩慢。ORMLite的createOrUpdate似乎很慢 - 什麼是正常速度?

我有一個非常簡單的對象(Item)與2整數(一個是generatedId),Stringdouble。我使用下面的代碼測試(粗略地)更新數據庫中的對象(100次)的時間。日誌聲明日誌:

時間更新1行100次:3069

爲什麼要過3秒鐘,以更新對象100倍,在一個表中,只有1行。這是正常的ORMLite速度?如果不是,可能是什麼問題?

RuntimeExceptionDao<Item, Integer> dao = 
    DatabaseManager.getInstance().getHelper().getReadingStateDao(); 
Item item = new Item(); 
long start = System.currentTimeMillis(); 
for (int i = 0; i < 100; i++) { 
    item.setViewMode(i); 
    dao.createOrUpdate(item); 
} 
long update = System.currentTimeMillis(); 
Log.v(TAG, "time to update 1 row 100 times: " + (update - start)); 

如果我創建100個新行,則速度會更慢。

注意:我已經在使用ormlite_config.txt。它記錄"Loaded configuration for class ...Item",所以這不是問題。

謝謝。

回答

23

不幸的是,這可能是「預期」的速度。確保您使用的是ORMLite 4.39或更高版本。 createOrUpdate(...)正在使用更昂貴的方法預先測試數據庫中的對象的存在。但我懷疑這將是一個最小的速度提升。

如果我創建100個新行,則速度會更慢。

默認情況下Sqlite處於自動提交模式。有一件事是嘗試使用ORMLiteDao.callBatchTasks(...)方法來包裝插頁(或您的createOrUpdate)。

In BulkInsertsTest android unit test,以下doInserts(...)方法插入1000個項目。當我把它叫做:

doInserts(dao); 

在我的模擬器中需要7.3秒。如果我打電話使用callBatchTasks(...)方法,它在包裝Android的SQLite的通話圍繞交易:

dao.callBatchTasks(new Callable<Void>() { 
    public Void call() throws Exception { 
     doInserts(dao); 
     return null; 
    } 
}); 

它需要1.6秒。使用dao.setSavePoint(...)方法可以獲得相同的性能。這將啓動一個交易,但並不像callBachTasks(...)方法好,因爲你必須確保你關閉了自己的事務:

DatabaseConnection conn = dao.startThreadConnection(); 
Savepoint savePoint = null; 
try { 
    savePoint = conn.setSavePoint(null); 
    doInserts(dao); 
} finally { 
    // commit at the end 
    conn.commit(savePoint); 
    dao.endThreadConnection(conn); 
} 

這也大約需要1.7秒。

+0

謝謝! callBatchTasks方法使其速度更快,如果不是完美的話,它會使速度變得好起來。當用戶滾動時,300毫秒會導致小的混亂(我猜測)。唯一的解決辦法是將它移入單獨的線程? – Frank 2012-08-01 15:22:50

+0

轉移到單獨的線程,如果你確實可以在後臺執行它,則肯定不會阻止用戶界面。你可以試試@Frank。 – Gray 2012-08-01 15:25:28

+1

在此腳本中,[documentation](http://ormlite.com/javadoc/ormlite-core/doc-files/ormlite_5.html#index-callBatchTasks)在示例中顯示無效(舊?)語法'callBatchTasks'(第一個參數是ConnectionSource)。 – Czechnology 2015-06-28 10:21:33