Delphi アプリの起動速度を上げる (または起動時間を短縮する) ために何をしますか?
アプリケーション固有のもの以外に、常に機能する標準的なトリックはありますか?
注: 高速なアルゴリズムなどについて話しているのではありません。速度に関しては、起動時のパフォーマンスのみが向上します。
4367 次
11 に答える
27
プロジェクト オプションでは、事前にすべてのフォームを自動作成しないでください。必要に応じて作成し、解放します。
于 2009-07-12T06:43:26.860 に答える
19
メイン フォームの OnCreate イベントでできる限り少ないことを試してください。むしろ、一部の初期化を別のメソッドに移動し、フォームがユーザーに表示されたら実行します。ビジー状態のマウス カーソルでアプリがビジー状態であることを示すインジケーターは、大いに役立ちます。
行われた実験によると、まったく同じアプリケーションに起動通知を追加するだけで、ユーザーは実際にそのアプリの起動が速くなると認識します。
それ以外に、デバッグ情報を除外したり、コンパイラで最適化を有効にしたりするなど、通常のことを行うことができます。
その上、すべてのフォームを自動作成しないでください。必要に応じて動的に作成します。
于 2009-07-12T06:42:49.607 に答える
17
さて、Argalatyr が示唆したように、コメントを別の回答に変更します。
「フォームを自動作成しない」という回答の延長として (それ自体が非常に効果的です)、最初に必要になるまで、データベース、インターネット、COM サーバー、および周辺機器への接続を開くのを遅らせることをお勧めします。
于 2009-07-12T16:21:51.417 に答える
13
フォームが表示される前に、次の 3 つのことが行われます。
- すべてのユニットのすべての「初期化」ブロックは、「最初に見た」順序で実行されます。
- すべての自動作成フォームが作成されます (DFM ファイルからロードされ、その OnCreate ハンドラーが呼び出されます)。
- メイン フォームが表示されます (OnShow と OnActivate が呼び出されます)。
他の人が指摘したように、少数のフォームのみを自動作成する必要があり (特に、それらが多くのコンポーネントを含む複雑なフォームである場合)、それらのフォームの OnCreate イベントに長時間の処理を入れるべきではありません。たまたまメイン フォームが非常に複雑な場合は、再設計する必要があります。1 つの可能性は、メイン フォームをオンデマンドでロードされる複数のフレームに分割することです。
初期化ブロックの 1 つが実行に時間がかかっている可能性もあります。確認するには、プログラムの最初の行 (.dpr ファイルのメインの 'begin..end' ブロック) にブレークポイントを置き、プログラムを開始します。すべての初期化ブロックが実行され、ブレークポイントが実行を停止します。
同様の方法で、メイン プログラムをステップ実行 (F8) できます。自動作成された各フォームが作成されるのにかかる時間が表示されます。
于 2009-07-12T07:29:46.563 に答える
4
スプラッシュ スクリーンを表示して、長い起動時間に気付かないようにします :)。
于 2009-07-12T16:27:41.030 に答える
2
アプリケーションのデプロイメントは、開発者が考慮していなかった方法で発生する可能性があります（通常は発生します！）。私の経験では、これは誰もが望むよりも多くのパフォーマンスの問題を生成します。
一般的なボトルネックはファイルアクセスです。アプリケーションの起動に必要な構成ファイル、iniファイルは、開発者のマシンでは十分に機能しますが、さまざまな展開状況では非常に小さく機能します。同様に、アプリケーションロギングは、ファイルアクセスの理由であろうとログファイルの増大であろうと、パフォーマンスを妨げる可能性があります。
私がよく目にするのは、Citrix環境または共有ネットワークドライブに展開されたリッチクライアントアプリケーションです。インフラストラクチャチームは、ユーザーの一時ファイルまたは個人用ファイルを、アプリケーションが問題を見つけた場所に保存することを決定します。これにより、パフォーマンスまたは安定性の問題に。
アプリケーションのパフォーマンスに影響を与えることがよくあるもう1つの問題は、データをファイルにインポートおよびエクスポートするために使用される方法です。Delphiのビジネスアプリケーションでは一般的に、DataSetで機能するエクスポート機能（反復処理とファイルへの書き込み）が見られます。ファイルへの書き込みに使用される方法、使用可能なメモリ、書き込み/読み取りの「フォルダ」がマシンに対してローカルであるか、リモートサーバー上にある可能性があることを考慮してください。
開発者は、これらはインストールの問題であり、懸念の範囲外であると主張する場合があります。私は通常、この種の問題が「インフラストラクチャの問題」として識別される前に、開発者による分析のサイクルを何度も目にします。
于 2009-07-13T14:49:18.490 に答える
2
起動時に実行する必要がある長時間実行タスク (データベース接続を開く、アプリ サーバーに接続するなど) をスレッドに配置します。これらのタスクに依存する機能は、スレッドが完了するまで無効になります。
ただし、それは少しチートです。メイン フォームはすぐに表示されますが、起動時間が短縮されているように見えるだけです。
于 2009-07-18T22:14:40.673 に答える
2
これは IDE だけのものですが、Chris Hesick は、デバッガーでの起動パフォーマンスの向上に関するブログ投稿を作成しました。
于 2009-09-22T17:07:06.307 に答える
2
最速のコード - 決して実行されないコードです。本当に明白です;）
于 2009-07-13T06:46:48.263 に答える
2
ASPackやUPXなどを使用して、実行可能ファイルと dll を圧縮します。解凍時間は、読み込み時間の短縮によって補われます。
UPX は、FireFox をより速くロードする方法の例として使用されました。
exe 圧縮には欠点があることに注意してください。
于 2009-07-18T23:48:25.303 に答える
2
- 最初に行うことは、自動作成されたフォーム リストをクリアすることです ([プロジェクト オプション] を探します)。特にアプリケーションがデータベース接続 (データモジュール) またはコントロールを多用するフォームを使用する場合は、必要に応じてその場でフォームを作成します。
- フォームの継承を使用して exe サイズを縮小することも検討してください (リソースの使用量が最小限に抑えられます)。
- フォームの数を減らし、類似または関連する機能を 1 つのフォームに統合する
于 2009-07-17T11:07:23.063 に答える