Blazkowiczchabapokя бы сразу в стрнгбилдере конструировал групповой инсерт, прамо из входящих данных, и по достижении определенного размера - отправлял его на выполнение.
Что это даст? Каждый новый SQL запрос будет парсится заново если значения заинлайнить.

А разве есть способ избежать повторного парсинга? Помоему, такого способа нет. Если мы засовываем данные через PreparedStatement, то вставка идет по одной строке и накладные расходы процентов на 20 больше. Сэкономили на парсинге - проиграли в других местах.


А если SSD? Андроид ведь.[/quot]
судя по задаче, маловероятно.


BlazkowiczНа самом деле вычитка пройдёт намного быстрее чем инсерты, поэтому не на что это особо не повлияет. Но есть смысл ограничить размер очереди, чтобы всё в памяти не держать, а заблокировать чтение на время, пока набор данных сбросится в базу.


к сожалению (или к счастью) операционка начинает распараллеливать одновременный доступ к нескольким файлам, при определенных условиях seek-и головки все сьедают. И задача у топикстартера такая, что ему на эти условия очень легко нарваться.


BlazkowiczSQLite же.
Не замеитл :) Действительно. Ну, с SQLite все значительно проще. Какие головки? Какие потоки? Надо все инсерты сделать в одной транзакции. Будет около 1 секунды на его 50000 записях, скорей всего.

WalterSullivan1 Пробовал вместо одной транзакции на 50 000 делать 50 транзакций по 1000, тоже не быстрее.

Учитывая ваш говнокод, я уверен, что вы действительно уменьшили кол-во транзакций. И к тому же, зачем давать 50 по 1000, сделайте одну по 50000.

Там у sqlite есть, насколько помню, несколько режимов работы, один из них - когда базу можно юзать из независимых процессов. Он же самый медленный, и он по умолчанию, однако поиграться другими режимами, но все равно у sqlite основной кушатель времени - это закрывание транзакций.


WalterSullivan1Сейчас пытаюсь распараллелить как советовал Blazkowicz .

Я под андроид ничего не делал, однако навскидку я не могу назвать распараллеливание под андроидом хорошим решением. Распараллеливание полезно там, где железо имеет много ядер. Андроид, все же, не xeon, ядер как правило там мало, очень часто одно. И если вы наплодите десятки потоков - вы сделаете только хуже. Нормально - когда кол-во потоков чуть больше или равно кол-ву ядер.

Blazkowicz,

1. разве внутри драйвера SQLite такого отделения не сделано?
2. пусть он посчитает через System.currenttimeMillis() сколько у него суммарно длится выполнение внутри его инсерта. Как-то я не доверяю профайлеру, замечал что он не всегда корректно показывает. Если его значение получится близко к 100% от всего выполнения, то параллелить нет смысла, даже если движок БД это не делает. Как-то так:

long t=0;
...
long before = System.currenttimeMilles();
stmt.executeInseert()
t = t+ (System.currenttimeMilles()-before);
...

И вконце сравнить t с временем выполнения всей программы.

WalterSullivan1,

подозреваю, что у вас там к тому же индексы сделаны неправильно. Очень часто (всегда) сталкивался, что люди ставят целую кучу лишних индексов, но при этом не ставят нужных. В результате у них база тормозит - а они начинают делать какие-нибудь многопоточные оптимизации. Правда это к mysql больше относится, но думаю что ситуация с sqlite не лучше