1 и 2 да, дали прирост процентов в 30 (всё на том же HTC Desire в варианте нс С++)
3 — нет, у меня нет форен кеёв.
4 — индексы по новым значениям строю после всех вставок, исследовали что это быстрее вот тут
Да и вообще там много интересных идей, как в самой статье, так и в ответах.
5 — с совсем выключенным журналированием тоже быстрее процентов на 15-20.
Итог, PRAGMA-ми можно добиться тоже не плохих результатов.
Спасибо.
Можно было, но как я уже писал в комментариях, я выбрал путь который выбрал.
Основной посыл статьи наверно не в том как решать такие задачи, а показать ошибки в работе с SQLite (ошибки который приводят к ухудшению производительности), и показать какую даёт прибавку переход на нативный уровень.
Не совсем понял как бы это помогло мне быстрее делать Update в базе данных?
Можете поподробнее расписать как это помогло вам?
Т.е. вы предлагает спрятать всю работу с SQLite базой за моделью ContentProvider-ов? Но как это сможет отразится на производительности?
Да. Всё верно. Это поддерживается.
Просто примеры кода с 3мя запросами.
Надо упомянуть об этом в статье. Я до этого тоже не сразу додумался, хотя очевиднейшее улучшение.
Спасибо.
Ну. Всё приложение строится вокруг этой базы с информацией о городах, и от того, сколько в том или ином языке в базе есть названий. Т.е. как раз названия на том или ином языке — и есть базовая вещь. Всё в приложении вертится вокруг них. Рассматривался вариант качать отдельную базу для каждого языка (базу только с переводами), но это большое дублирование информации, как минимум на уровне айдишников (ведь в каждой базе будет 40 000 одних и тех же айдишников для связки полей). Хотя наверно и такой вариант подошёл бы :)
Но я выбрал тот путь что выбрал, и в итоге получился интересный исследовательский труд, да и результат тоже был достигнут. Исходная АПК не слишком велика, а языков поддерживается много.
Да. Рассматривался.
Он делает всё тоже самое что мы тут вместе с execSQL, готовит строку, подготавливает стейтмент, байндит к нему значения. В общем не быстро. Это можно посмотреть в исходниках андроида, что там внутри.
Посмотрите метод public long insertWithOnConflict из «Android SDK\sources\android-14\android\database\sqlite\SQLiteDatabase.java»
Там 2 пылинки. Просто диафрагма задрана на первой фотке аж до 22 -потому так чётко их видно.. Они же обе и на втором примере видны в тех же самых местах, но уже бледнее.
Чёткость пылинки, как тут уже писали в коментариях, зависит не от зума, а от диафрагмы. Чем больше диафрагма — тем чётче пылинка. Добавил в UPD1 2 примера фоток. На первой пылинки сверх-чёткие, потому как там диафрагма выставлена аж в 22, на втором же снимке диафрагма 11 и как видим пыль гораздо более размыта. Но по идеи для gimp-heal или gimp-clone всё-равно что закрывать, главное что бы радиусом он был больше чем самый размытый варианта пылинки. Я делал именно так, не заморачивался с изменением радиуса под разную чёткость пылинок. Я просто выставлял радиус побольше, что бы уж наверняка
3 — нет, у меня нет форен кеёв.
4 — индексы по новым значениям строю после всех вставок, исследовали что это быстрее вот тут
Да и вообще там много интересных идей, как в самой статье, так и в ответах.
5 — с совсем выключенным журналированием тоже быстрее процентов на 15-20.
Итог, PRAGMA-ми можно добиться тоже не плохих результатов.
Спасибо.
PRAGMA synchronous = OFF
PRAGMA journal_mode = MEMORY
Основной посыл статьи наверно не в том как решать такие задачи, а показать ошибки в работе с SQLite (ошибки который приводят к ухудшению производительности), и показать какую даёт прибавку переход на нативный уровень.
Можете поподробнее расписать как это помогло вам?
Т.е. вы предлагает спрятать всю работу с SQLite базой за моделью ContentProvider-ов? Но как это сможет отразится на производительности?
Просто примеры кода с 3мя запросами.
Надо упомянуть об этом в статье. Я до этого тоже не сразу додумался, хотя очевиднейшее улучшение.
Спасибо.
Но я выбрал тот путь что выбрал, и в итоге получился интересный исследовательский труд, да и результат тоже был достигнут. Исходная АПК не слишком велика, а языков поддерживается много.
Он делает всё тоже самое что мы тут вместе с execSQL, готовит строку, подготавливает стейтмент, байндит к нему значения. В общем не быстро. Это можно посмотреть в исходниках андроида, что там внутри.
Посмотрите метод public long insertWithOnConflict из «Android SDK\sources\android-14\android\database\sqlite\SQLiteDatabase.java»