ライブビューのパフォーマンスについて最初に考慮する必要があるのは、ライブビューの機能には必然的に代償が伴うということです。ベースデータとの同期を維持するようにビューを保守する作業は最適化されており、高速に実行されます。それでも、ベースデータを変更したりビューを保守するには、いくらかのリソースが消費されます。また、ビューに最初にデータを挿入する際にも、さらに追加リソースが消費されます。この代償はそれほど大きくありませんが、存在することに変わりはなく、主にメモリ消費量の増加という形で現れます。ライブビューにデータが挿入されると、メモリ内に何らかの内部データが作成され、ベースデータが変更されると、その内部データを使用して高速にビューが保守されます。
この追加メモリ消費量は適度なもので、結果のリスト自体に必要なメモリ量とほぼ同じです。このため、ライブビューの機能に必要な追加リソース量が低から中程度であるとしても、ライブビューは、クエリーの結果をライブの状態に保つ必要が本当にある場合、つまりその結果が何度も必要になり、ベースデータが変化しているために結果も変化する場合にのみ使用した方がよいことは明らかです。
ライブビューのパフォーマンスには、このほかにも２つの側面があります。
クエリーパフォーマンスとは、クエリーの実行時に、ビューに最初にデータが挿入されるまでの時間（または、クエリーを再実行してデータが再挿入されるまでの時間。「View.Rebuild」を参照）を言います。クエリーパフォーマンスについては、「LiveLinq クエリーパフォーマンス：論理的な最適化」および「LiveLinq クエリーパフォーマンス：インデックスパフォーマンスの調整」で説明しています。
ベースデータの変更時にライブビューを保守する作業は、インクリメンタルビューメンテナンスと呼ばれる技術を使用して最適化されています。これは、ビューにデータが単純に再挿入されるということではなく、ビューがより精巧な方法でベースデータの変更に対応することを意味します。このビューの更新は、ローカルでインクリメンタルに行われ、ベースデータの差分からビューの差分が計算されます。ほとんどの場合、この処理は高速で、ユーザーがパフォーマンスを特に調整する必要はありません。
ビューの保守にかかる時間を見積もるための目安として、その時間は、ビューの結果コレクションの中の変更された項目（追加または削除された項目を含む）の数にほぼ比例すると言えます。このため、ベースデータの変更の結果として少数の項目だけが変更された場合、ビューの保守時間は極めて短く、おそらくは無視できる程度です。ただし、ビューの結果のかなりの部分が変更される場合は、保守にかかる時間も相応になります。たとえば、結果リストの半分が変更される場合は、最初からクエリーし直すより、ビューの保守の方がコストがかかることさえあります。
最後に、ビューの保守のパフォーマンスは、そのクエリーパフォーマンスとは関係がないという点は重要です。ビューに最初にデータが挿入されるまでの時間は重要ではありません。保守にかかる時間はほぼ同じで、データ全体のサイズではなく、変更（差分）のサイズに左右されます。