1

それをベンチマークするつもりでしたが、大変な作業なので、前にはっきりとした答えを見逃していないか確認したいと思います。

サブクエリを使用して各行の詳細を取得する巨大なクエリがあります。

次に、各行はListViewにプラグインされたListAdapterで使用されるため、別のループが各行を1つずつ取得してListItemにします。

何がより効率的だと思いますか：

  • 最適化を行うためにSQLエンジンを頼りに、SQLの混乱の中でサブクエリを保持します。
  • ListAdapterループでサブクエリを取得するので、ディスプレイに詳細を遅延ロードします。はるかに読みやすくなりますが、ヒットが多すぎるとプロセスが遅くなるのではないかと思います。

2つの重要なこと：

  • サブクエリを取り除くために大きなSQLチャンクを書き直すことはできません。私はそれがより良いだろうと知っていますが、私はそうすることができませんでした。
  • 私の知る限り、リストには10​​00を超えるアイテムは含まれず、デスクトップアプリであるため、同時実行性はありません。その場合、これはパフォーマンスを気にすることにも関係がありますか？そうでなければ、とにかくトラフィックの多いWebサイトの回答に興味があります。知っておくといいです...
4

2 に答える 2

2

SQlite は驚くほど優れた小さなエンジンですが、特別に巧妙な最適化を行っているわけではありません。1 つの大きな利点 (制限内で使用する場合) は、インプロセスで実行できるため、複数のクエリのオーバーヘッドが 1 つの大きなクエリに比べて非常に小さいことです。それがコード化するのが最も簡単である場合、特定のユースケースについて、私はそれを本当に検討します（そして、あなたが示唆するように、「遅延読み込み」の方法でそれを行うと、実際にはデータの最初の画面がより速く表示される可能性があります!)。ご想像のとおり、これがユースケースでパフォーマンスのボトルネックになる可能性は低いため、よりシンプルで信頼性の高いコーディングを行うことは重要なプラスです。

トラフィックの多いサイトを運営していて、PosgtreSQL、Oracle、SQL Server、DB2 などのリッチで「重い」エンジンを使用している場合は、オプティマイザーをもっと信頼するでしょう。しかし、私が気づいたことの 1 つは、(残念ながら、常にではありませんが) サブクエリを結合に変更できることが多く、それによってパフォーマンスが向上する傾向があることです (結合により、オプティマイザが適切なインデックスを使用しやすくなる、と私は思います - - SQL オプティマイザーを自分でコーディングしたことはありませんが、それは、クエリの代替形式の多くのエンジンからのクエリ実行プランをじっと見てからの私の印象です... もちろん、適切なインデックスがあると仮定します!-) --これはもちろん、問題の特定のケースのベンチマークで確認する必要がありますが、それは私の最初の作業仮定です。

于 2009-06-18T04:54:23.580 に答える
1

カーソルの使用はどうですか？

大きなクエリを使用して、SQLエンジンにクエリを最適化させたいと思います。また、「大きな」クエリを使用したりカーソルを使用したりする代わりに、SQLの外部でループを実行する方がよい例は考えられません。

しかし、何が良いかを知る最良の方法は、それをベンチマークすることです。

幸運を！

于 2009-06-16T07:28:14.033 に答える