Android数据库操作的执行时间的变化

时间:2012-07-13 23:21:41

标签: android database execution-time

我正在测量打开和关闭数据库的方法的执行时间,以及对其执行查询和插入。对于这四个操作中的每一个,我基本上都会在执行相关语句之前和之后得到时间,如下所示:

for(int i = 0; i < 500; i++) {
    startTime = System.nanoTime();
    long insertResult = db.insert(tableName, null, contentValues);
    endTime = System.nanoTime();
    if(insertResult > -1) {
        generateNoteOnSD(fileName, (endTime - startTime));
    }
}

在插入的情况下:

  • 样本中的最短执行时间为13毫秒(毫秒)
  • 样本中的最长执行时间为537 ms
  • 结果集的50%以上(来自500的259'插入'执行)在15到20毫秒之间。
  • 20 ms以上的值频率非常低(1,2或3)。

有人可以就系统如何执行此类操作向我提出想法/方向吗?我真的不知道如何进行持久存储的写操作以及它依赖于哪些因素。我想知道这是为了解释上述测量(为什么同一操作的执行时间的变化)。

非常感谢任何帮助。

奥克塔维奥

1 个答案:

答案 0 :(得分:2)

我将假设这是一个常规表,而不是临时表。

让我们从这里最大的表现开始。

默认情况下,每个此类插入都会启动和结束新事务。如果你想加快速度,请运用

db.beginTransaction();
循环之前

db.setTransactionSuccessful();
db.endTransaction;
循环后

。这将把所有插入放在同一个事务中。一定要测量花费总时间的db.endTransaction的时间。当您没有手动调用这些操作时,每个db.insert都隐式包含在那些操作中,这称为隐式事务

虽然事务协议本身很复杂并且会导致某些性能差异,但细粒度事务会导致硬件速度的差异。事务需要持久,因此它们需要写入到闪存(写入甚至比读取慢,并且每个事务需要多次写入)。相反,“一个长事务”写入易失性存储器,即使数据需要在提交期间转到闪存,您只需要一小部分写入。如果您的行很窄,这种效果会更清晰,因为更多行将适合闪存块并立即写入。

就读取而言,交易在这里扮演的角色较少。这很容易。如果您的应用程序在易失性RAM中很热,那么所有数据都会从那里开始。如果不是,则数据来自闪存。

数据的高峰可能归因于与数据库竞争的无关背景流程。仅当这些应用程序进行密集计算时才会发生这种情如果其中一些进程访问同一个数据库,您也可能会遇到锁争用;即使这些进程正在等待其他事情,这也是可能的。这也可以解释为什么他们的分布是如此不规则。这不是唯一的可能性。

有关SQLite中使用的算法的一般概述,查看this本书可能很有用,尽管它是为竞争操作系统编写的。