Почему устарела InsertHelper?

Я потратил довольно много времени на некоторые проблемы с производительностью на нашем устройстве и заметил, что у нас есть довольно много приложений, которые делают db-чтение/запись.Почему устарела InsertHelper?

Я начал с использования API контактов для вставки новых контактов & строк данных, и это было болезненно медленным. 1 минута 18 секунд, чтобы вставить около 1500 строк (250 необработанных контактов & 1250 строк данных).

Я использовал вспомогательную вставку в другом приложении для вставок производительности и решил написать тестовое приложение, которое будет писать для разделения db w/отдельные методы вставки.

В каждом db есть одна таблица, каждый w/4 столбца: _ID, Name, Time и Blob (все типы «строка») - точно так же, как поставщик контактов определяет столбцы данных.

_ID is auto increment pk, Name просто вставляет то же самое «1234567890», время - это только текущее системное время в milis, а BLOB - это строка длиной 6400, заполненная буквой «A» ...

я первый проверил массовой вставки, но все это делает петли через все вставки вы определили, и так же медленно, как делать вставки по отдельности (или пренебрежимо малое влияние на производительность) ..

я тестировал 3 различных методы для вставки: ContentValues w/db.insert метод: SQLiteStatement w/statement.execute() (выполняется внутри транзакции). SqliteInsertHelper с транзакцией.

Я могу предоставить код, но я получил максимальную производительность от InsertHelper, и интересно, почему она устарела:

Время для вставки 100 записей ContentValues: 7.778 секунды (82 байта написано/мс) SQLiteStatement: 1.311 секунд (489 байт в секрете/мс) SqliteInsertHElper: 0,92 секунды (2197 байт в сек./Мс)

Любые идеи?

источник

2013-03-08 Chrispix

Я сделал некоторые дополнительные испытания, и сделал очередную вставку, но сделал это часть сделки, это улучшило производительность значительно. Похоже, какой-то код, вероятно, необходим, чтобы уступить (глядя на поставщика контактов). – Chrispix

Учитывая указанную выше проблему производительности, транзакции были моим первым предложением (каждая транзакция требует ожиданий с обратной связью в оба конца, каждая вставка вне транзакции неявно завернута в одну). Прошлое, это может быть полезно прочитать: http://stackoverflow.com/questions/14344172/android-bulk-insert-when-inserthelper-is-deprecated – rutter

Я бы предложил также транзакции. Вставки, которые я тестировал с транзакциями, были довольно быстрыми. – Luis

InsertHelper позволяет пользователям делать несколько вставок в таблицу, используя тот же оператор. Но это не очень хороший способ вставить как таковой, как not thread-safe.

источник

2013-10-31 05:35:33 Pihu

в соответствии с http://developer.android.com/reference/android/database/sqlite/SQLiteStatement.html, альтернативная рекомендация не является потокобезопасной. –

Вы должны использовать transactions.. Если вы явно не создаете транзакцию для операции с базой данных, фреймворк создает по одному для каждого. Сгруппируйте свой объект вместе и вставьте все сразу. Это значительно повысит производительность.

источник

2014-05-23 07:26:21 interlude

Трудно найти какую-либо информацию о том, почему InsertHelper устарел, не переходя к фактическому фиксации, который его осуждает. Инженер, который отказался от InsertHelper, дал следующую причину:

Этот класс не имеет никаких преимуществ перед SQLiteStatement и просто делает код более сложным и подверженным ошибкам.

После реорганизации из InsertHelper в SQLiteStatement я согласен. Одно исключение - для нулевых функций привязки. В то время как InsertHelper автоматически вызывает bindNull() для вас, SQLiteStatement падает, если вы передаете, например, нулевую строку, и перед вызовом bindString() вы должны выполнить свою нулевую проверку.

См: https://android.googlesource.com/platform/frameworks/base/+/b33eb4e%5E!/

источник

2015-10-09 23:45:53

Упрощенный для перехода в журнал фиксации, чтобы получить авторитетный ответ. Дал бы вам больше, если бы мог. – Dalbergia

Почему устарела InsertHelper?

ответ

Смежные вопросы