一般の Movable Type ユーザー（私を含めて）は、共有のレンタルサーバーを借りていると思います。共有のレンタルサーバーは、一般的に言って混雑しています。それでも、再構築に問題なければ Movable Type を使い続けると思います。何故なら、Movable Type には、カスタマイズが素人にも比較的簡単にできるからです。１歩１歩カスタマイズしていく魅力を味わえるからです。
再構築に少し問題が出てくる（Internal Server Error とか出る）ようであれば、ユーザーは、部分的にダイナミック・パブリッシングにしようか、Perl版ダイナミック・パブリッシングしようか、あるいは、WordPress に乗り換えるか考えます。
賛成です。
一般の Movable Type ユーザー（私を含めて）は、共有のレンタルサーバーを借りていると思います。共有のレンタルサーバーは、一般的に言って混雑しています。それでも、再構築に問題なければ Movable Type を使い続けると思います。何故なら、Movable Type には、カスタマイズが素人にも比較的簡単にできるからです。１歩１歩カスタマイズしていく魅力を味わえるからです。
再構築に少し問題が出てくる（Internal Server Error とか出る）ようであれば、ユーザーは、部分的にダイナミック・パブリッシングにしようか、Perl版ダイナミック・パブリッシングしようか、あるいは、WordPress に乗り換えるか考えます。
ダイナミック・パブリッシングやPerl版ダイナミック・パブリッシングに切り替えた場合、まずしなければならないのが、再構築なんです！！。この最初で最後の再構築に難儀することが多いです。最後まで問題なく再構築できればいいのですが、それが完遂できないこともあります（もちろんサーバーが混雑しているからです）。それで、にっちもさっちもいかなくなって WordPress に乗り換えてみると同じサーバーなのに問題なく動くことが多い（ただ、プラグインを多く入れて動かしていると、管理画面が白くなることもあります、メモリー不足で。だから、WordPress にも WordPress なりの弱点はあります）。
スタティックからダイナミックに切り替えた直後の再構築をしなくてよい仕組みにできないものでしょうか？
現在の再構築は、必要な回数だけループ処理をしているため、1) ループの回数を減らす。2) 一回のループの処理時間を短くする といった方向で検討できます。すなわち、再構築には、改善できる余地がまだ残っています。たとえば、RebuildAt1stView プラグインは、1) を実現する方法の 1 つですね。
ダイナミックパブリッシングは、File not found (404 error) をトリガーにするために、対象となっているファイルを削除したりしなければいけないので、ブログ全体に対して処理している様子です。
再構築の処理の改善については、様々なケースがあるため、なかなかうまい方法が無いことも事実です。なので、みなさんと一緒に MTQ でディスカッションしていきませんか。
話の流れにからずれてるかもしれませんが、デフォルトをダイナミックパブリッシングにして、スタティックをオプションにするのはいかがでしょうか？
そうすればスタティックの必要性（魅力）を感じている人だけが、再構築という作業認識することになり、MTは再構築があって嫌だみたいな変な誤解がなくなると思います。
デフォルトがダイナミックパブリッシングはいいアイデアですね。
ただしPHPダイナミックじゃなくて、Perlダイナミックにしてほしいと思います。
必殺ちゃぶ台返し。
疑問なんだけれど再構築ってそんなにネックかしら？ そりゃ速いということに越したことはないけれど、優先度としては低い気がするなぁ。というのも、記事を書く→公開保存する→ちょっと長く待たされる(20秒くらい)→完了というわけで自分は別に問題とも思っていないので(´･ω･`)
あと、全体再構築に数時間かかるとか言うけれど(自分のブログでも20分)いいんじゃないの？と思う。だって毎日全体再構築するわけでもないし、再構築の間、始終ダイアログを監視し続ける必要もないですし。
コミュニティでアンケートを取れたらいいんですけどね。記事数と再構築時間の統計を取って、使用者全体におけるのパフォーマンス統計がないと個々のケースで速い遅いエラーになる、というだけで終ってしまうんでないかい？と。SAにそういうデータはないのかしら？
１時間でも２時間でも確実に再構築されるなら、私は待ちます。
でも、個人ユーザーが借りているレンタルサーバーでは、10分あるいは20分すると、Internal Server Error （500エラー）が出てしまうレンタルサーバーがあるのも事実です。
個人ユーザーを切り捨てる、というのであれば（多くの個人ユーザーが去っていった、というのが私の認識です）、上のような主張もありかもしれませんが。
具体的に Internal Server Error が出てしまうレンタルサーバとはどこのサービスでしょうか？ サーバスペックなどが具体的に判れば、議論がより明快になって良いと思います。
ちなみにさくらインターネットのスタンダードプラン(Intel Pentium M 2.00GHz )では負荷によるエラーは今まで遭遇したことがありません。参考まで。
あぁ、書き忘れた。再構築を問題にする場合には；
a. 再構築(全体or公開保存時)の所用時間が長いことを改善したい
b. 再構築(全体or公開保存時)がそもそも不可能なことを改善したい
のか、その方針を明確にしないと議論が発散すると思った。
２つに分ける（悟性主義！）までもなく両方だと思います。
まずはPerl版のDynamic Publishing について、検討要望のケースを登録しました。
http://bugs.movabletype.org/default.asp?104065
http://bugs.movabletype.org/default.asp?W37
また、再構築の操作をノンブロッキング形式にしたいという要望が別途ケースとして存在します。
http://bugs.movabletype.org/default.asp?53366
再構築のパフォーマンス向上は、継続的に取り組まなければ行けない課題として認識しています。もし、こちらについてパフォーマンス向上につながる技術面でのアイデアなどがありましたら、ぜひフィードバックいただければと思います！
ダイナミックパブリッシングを使わないことを前提として、以下は有効だと思います。
(1) 更新の確認ロジックの見直
現在、build_page で計算した結果と、既存のファイルの内容を比較して、更新の有無を確認しています。この方法では、必ず Disk I/O が発生しているので、これの見直しは重要かと思います。
a. 既存のファイルの情報を DB/キャッシュ に格納
現在、Digest::MD5 が有効であれば、ハッシュ値と build_page の計算結果を比較しています。このハッシュ値を、DB (mt_fileinfo) に格納しておくことで、Disk I/O を増やすことなく比較ができると思います。
b. 比較ロジック自身の見直
現在は、ハッシュをの有無に関係なく、データ全体を比較するという方法を採用しています。たとえば、modified_on の情報をベースにすることで、若干早くなると思います。
(2) 日付アーカイブの作成ロジックの見直
現在、日付アーカイブは、その再構築処理の対象のブログ記事の数だけ、作成するループ処理が発生しています。当然、同じ日付アーカイブが出力されていたらスキップするのですが、この処理をもう少しスマートにできないかと思っています。
＞(1) 更新の確認ロジックの見直
いいアイデアですね。データの比較処理は結構ボトルネックになっている気がしました。
公開キューでバックグラウンド再構築しつつ、まだ再構築が終わっていないページにアクセスされた時にはRebuildAt1stViewで再構築する、というような仕組みも欲しいです。
ややこしいシステムを作ることが多い立場から少し
再構築パフォーマンス向上はとても歓迎なのですが、
バックグラウンドでいつか再構築されています。アクセスがあったら適宜再構築しますといった方向だけだと、他のシステムとの連携用にMTを利用しているケースの場合、再構築終了＝>rsyncみたいな場合に恩恵がないです。
1 再構築そのものの負荷を下げ、パフォーマンスを上げる
2 再構築を確実に完了するための仕組みを考える
3 再構築が与える心理的な負担を減らす
4 再構築をなくす。ただし拡張性を犠牲にしない
１番はすべての立場に恩恵があると思いますが、
その他は、それぞれにニーズがあると思います。
これらを再構築でひとまとめにせず、
個別のリクエストとして対策を行っていく必要があると思います。