Delphiコードの完成度

私はいくつかの大きな（〜600k行のコード）Delphiプロジェクトを持っています。私たちのチームが開発したカスタムコンポーネントがいくつか含まれています。Delphiコードの完成度

多くの場合、Ctrl +スペースでコード補完を呼び出すか、単に「。」を押すと、IDEがロックアップして、本当に難しいと思うことがあります。場合によっては、遅延が1分以上になることもあります。他の時には、すぐに提案がポップアップします。

デルファイのインテリセンスのパフォーマンスにどのような要素が影響しますか？このパフォーマンスを向上させる方法はありますか？

これまでのところ私の最高の解決策は、自動補完をオフにして、1分ほど静かに瞑想する必要があるときにCtrl +スペースを使用することです。

私はVS2005、VS2008、およびXCodeのすべてが、実質的に即座のインテリジェンスフィードバックを与えるように見えるとは言い難いですが（私はこれほど大きなプロジェクトでこれを試したことはありませんが）。

2009-05-22 JosephStyons

これは私に非常に興味があります。私はそれを覚えています。またはCtrl + Spaceは数年前に完全にうまく機能していました。 Delphi 7、確かにDelphi 5だと思いますが、遅れはほとんど分かりませんでした。私はそれが好きだった。しかし、D2005が登場しました。その時、私はこの機能にひどい問題を経験しました。何が変わったの？彼らはなぜそれを変えたのですか？ –

良い質問です。私は大規模なプロジェクトではほとんど使用できなくなりました。私はそれを断念してしまいました。オンラインヘルプはちょっと面倒で扱いにくいので、面倒です。 Ctrl-Spaceをもう一度使うことができればとっても便利です。 – robsoft

プロジェクトで使用されているすべてのユニット（*）をdprに明示的に含めるようにしてください。
検索パスに依存して別のユニットから呼び出されたユニットを検出して、それをdprに追加しないでください。 dprははるかに長くなりますが、コンパイルに関連するすべての作業はコード洞察力を含めてより高速になります。

（*）は、インストールされたコンポーネントのユニットではありません。

出典

2009-05-22 20:00:36

これは実際にかなり助けているようです... ctrl + f12は、プロジェクトに固有でないユニットの見苦しいリストを表示します...しかし、私はそれで生きることができます。 – JosephStyons

プロジェクト内の検索パスの他に、巨大なライブラリパスがあると、もう1つのひどいラグが入ります。 –

同様のケースで私を大いに助けてくれました。**未使用のユニット**を「使用」セクションから削除し、可能な限りユニットを「インプリメンテーション」から「インプリメンテーション」に移動することに大きな助けとなりました。 346kLocプロジェクトのコンパイル時間が70秒から8.8秒に短縮されました。これはコード補完に直接影響を与えました。今はほとんど瞬間です。 – Kromster

これはDelphiの長年にわたる問題です。自動補完を無効にする必要がありました。そのようにしばらく働いた後、私はとても満足していました。たとえわずか数分の1秒しかかからなくても、IDEの遅れがあると私の入力がわずらわしく、私の流れが中断されました。自動化機能を使ったほうがずっといいよ、IMO。

出典

2009-05-22 15:08:09 dwc

は「オートマチック」を使用しないと同意できません... –

マスターピーター：それぞれ自分自身に、私は恐れています。私が欲しいものが分かっているときは、一時停止してからピッキングするよりもずっと速くタイピングしています。私が欲しいものがわからないときは、私は確かにそれを知っていて、Ctrl + Spaceキーを押して何か助けを得ることができます。 – dwc

小さなプロジェクトでは、私はそれがすばらしかったことがわかりました。一度私はそれがどのように動作するかを学ぶと、私はコードテンプレートと自動補完を大きな利点に使用することができます。そうすれば、大規模なプロジェクトではパフォーマンスが低下します。 – JosephStyons

Delphi Code Insightは、ユーザーがCode Insight（Ctrl + Space、 '。'など）を要求したときにカスタムコンパイルを実行するためにコンパイラdllを呼び出します。このカスタムコンパイルはユニット内でビルドを行い、ファイルバッファの現在のオフセットに達するまでcodegen、リンクなどをスキップします。これを念頭に置いて、コンパイラが現在の位置に到達する前に見えるユニットリストは、Code Insight操作の速度を決定する大きな要因となります。多量のファイルシステムの依存関係などを引き起こすユニット（または複数のユニット）が存在する可能性があります。uses節の順序を変更したり、uses節を複数のファイルにリファクタリングしたり、uses節のunitsを削除したりすることは、現在のユニットをコンパイルするために必要なものがパフォーマンスを向上させる可能性があります。さらに、パッケージを使用するかユニット検索パスを短縮すると、CI応答時間が向上する可能性があります。

出典

2009-05-22 15:12:43

面白い答え、ありがとう！そこに思った食べ物。 :-) – robsoft

これは本当に興味深いです...しかし、私は、アプリケーションの完全なビルド（私たちの有名な高速コンパイラ、yay）は約1分かかると指摘しておきます。。 – JosephStyons

フル再構築（ディスクに.dcusを生成する）を行うと、CIのパフォーマンスが向上しますか？また、パッケージを使用していますか、それともモノリシックな.exeですか？ –

あなたがあるためにあなたのチームのカスタムコンポーネントのソースディレクトリを含めてください私はあなたが使用しているバージョンを知らないが、はるかに高速コード補完は、私は、Delphi 2009で一番

出典

2009-05-22 20:15:59

これは知っておきたいことです。私は現在d2007にいる – JosephStyons

が好きなものの一つですライブラリパス？コンポーネントのDCUファイルだけがライブラリパスにある場合、ソースファイルもそこにある場合と比べて、速度の違いを確認するのは面白いでしょう。

出典

2009-05-24 11:27:13 mjn

はい、カスタムコンポーネントのソースパスがあります。私はdcuのみのアプローチを試してみます – JosephStyons

私はDCUパスを試しましたが、intellisenseのパフォーマンスを変更するようには見えませんでした。 – JosephStyons

私はこの問題を自分自身に遭遇しました。私は、環境ライブラリパスから不本意なネットワークリンクを削除することで修正しました。私の問題を100％解決しました。

出典

2009-06-05 16:29:33

答えて

関連する問題