問題タブ [delphi-2009]

以下のコードを実行すると EAccessViolation が発生するのはなぜですか?

TWinControl でカスタム ヒントを表示しようとしていますが、その位置を取得する方法がわかりません。

position 0,0 を使用すると、画面の上部 (ウィンドウの外側) にヒントが表示されるので、画面上のコントロールの位置である必要があると思います。

編集：

期待どおりの値を返す TControl プロパティ ClientOrigin を見つけました。ClientOrigin.X と ClientOrigin.Y を使用するのは正しいですか?

Delphi 2006 で完全に Unicode 互換のアプリケーションがあります。すべての AnsiString を WideString に置き換え、すべての VCL コントロールを TNT コントロールに置き換え、すべての文字列関数を AnsiString から WideString に変更しました。すべてを元に戻す必要があるため、すべての作業が無駄になったようです。Delphi 2009 をだまして、Widestrings が実際には UnicodeStrings であると思わせる方法はありますか?

開発ツールに関しては、私はためらうアップグレード担当者です。私の製品の約半分はまだ D7 を使用しており、残りは D2006 です。

真実は、Unicode サポートは歓迎され、非常に便利ですが、現在のプロジェクトで得られるものよりも多くの問題を引き起こす可能性があるということです (多かれ少なかれ、すでに Unicode に対応しています)。特に、各文字列が以前の 2 倍のメモリを使用すると、パフォーマンスが大幅に低下する場合があります。

では、Unicode はさておき、アップグレードする他の主なインセンティブは何ですか?

私は Delphi 2009 を使用しており、いくつかの XML データを操作したいと考えています。そのための最も便利な方法の 1 つが nativeXML だと聞きました。どうすればこのライブラリをインストールできますか？

サイズが 24 MB (1 行あたり平均 17 文字) の 140 万行の大きなテキスト ファイルを読み込んでいます。

私は Delphi 2009 を使用しており、ファイルは ANSI ですが、読み取り時に Unicode に変換されるため、変換後のテキストのサイズは 48 MB であると言えます。

（編集：もっと簡単な例を見つけました...）

このテキストを単純な StringList にロードしています。

私は、データ行が 48 MB よりも多くのメモリを必要とするように見えることを発見しました。

実際、155 MB のメモリを使用しています。

Delphi が 48 MB または 60 MB を使用していても、メモリ管理のオーバーヘッドを考慮して問題ありません。しかし、155 MB は過剰に思えます。

これは StringList の障害ではありません。以前に行をレコード構造にロードしようとしましたが、同じ結果 (160 MB) が得られました。

Delphi または FastMM メモリ マネージャが、文字列を格納するために必要なメモリ量の 3 倍の量を使用する原因が何なのか、私にはわかりません。ヒープ割り当てはそれほど非効率的ではありませんよね?

私はこれをデバッグし、できる限り調査しました。なぜこれが起こっているのかについてのアイデア、または過剰な使用を減らすのに役立つアイデアは大歓迎です.

注: この「小さい」ファイルを例として使用しています。私は実際に 320 MB のファイルをロードしようとしていますが、Delphi は 2 GB を超える RAM を要求しており、この過剰な文字列要件のためにメモリが不足しています。

補遺: Marco Cantu が、Delphi と Unicode に関するホワイト ペーパーを発表しました。Delphi 2009 では、文字列あたりのオーバーヘッドが 8 バイトから 12 バイトに増加しました (さらに、文字列への実際のポインタの場合はさらに 4 バイト)。17x2 = 34 バイト ラインごとに 16 バイトが追加されると、ほぼ 50% が追加されます。しかし、オーバーヘッドが 200% を超えています。余分な 150% は何になるでしょうか?

成功！！皆様のご提案に感謝いたします。みなさん、考えさせられました。しかし、彼が尋ねたので、私は Jan Goyvaerts に答えを与えなければなりません:

...なぜ TStringList を使用しているのですか? ファイルは本当に別の行としてメモリに格納する必要がありますか?

その結果、24 MB のファイルを 140 万行の StringList としてロードする代わりに、プログラムが認識している自然なグループに行をグループ化できるという解決策にたどり着きました。そのため、127,000 行が文字列リストに読み込まれました。

現在、各行の平均文字数は 17 文字ではなく 190 文字です。StringList 行ごとのオーバーヘッドは同じですが、行数が大幅に少なくなりました。

これを 320 MB のファイルに適用すると、メモリが不足することはなくなり、1 GB 未満の RAM にロードされるようになりました。（そして、読み込みに約10秒しかかかりません。これはかなり良いです！）

グループ化された行を解析するために少し余分な処理が必要になりますが、各グループのリアルタイム処理では目立たないはずです。

(念のために言っておきますが、これは家系図プログラムであり、32 ビット アドレス空間に約 100 万人のすべてのデータを 30 秒以内にロードできるようにするために必要な最後のステップかもしれません。インデックスをデータに追加するための 20 秒のバッファがまだあります。これは、データの表示と編集を可能にするために必要です。)

名前でインデックス付けされた一連のオブジェクトを格納する TDictionary があり、すべてのオブジェクトを調べられるようにしたいと考えています。だから私はこれを試しました：

しかし、それはコンパイルされません。「互換性のない型: 'TMyObject' および 'TPair'

だから私はそれを少し違った方法で試しました：

それもコンパイルされませんでした。このエラー メッセージはさらに奇妙です: Incompatible types: 'TPair' and 'TPair'

どうやら、for .. inループで辞書を列挙するには、ある種のファンキーな文法が必要なようです。正しく宣言する方法を知っている人はいますか？

編集: Fabio Gomes は適切に動作する例を示しましたが、私のコードはまだ彼の方法を使用してコンパイルされません。別の部署で働いているからでしょうか？Value 側で使用するディクショナリとクラスは両方とも 1 つのユニットで定義され、このコードは別の場所にあります。それはコンパイラのバグになりますか？誰でもこれを確認できますか？

編集 2: 問題が見つかりました。 http://qc.embarcadero.com/wc/qcmain.aspx?d=69461興味のある方はどうぞ。

困惑しています。今日のCodeRageで、Marco Cantuは、CharInSetが遅いので、代わりにCaseステートメントを試す必要があると述べました。パーサーでこれを行ってから、AQTimeでスピードアップを確認しました。Caseステートメントの方がはるかに遅いことがわかりました。

4,894,539の実行：

CharInSet（P ^、[''、＃10、＃13、＃0]）ではありませんがinc（P）;を実行します。

0.25秒で計時されました。

しかし、同じ数の実行：

Trueは、     ''、＃10、＃13、＃0の
  ケースP ^を実行します：ブレーク;     else inc（P）;   終わり;

「whileTrue」の場合は.16秒、最初の場合は.80秒、その他の場合は.13秒かかり、合計で1.09秒、つまり4倍以上の長さになります。

CharInSetステートメントのアセンブラーコードは次のとおりです。

add edi、$ 02
mov edx、$ 0064b290
movzx eax、[edi]
call CharInSet
test a1、a1
jz $ 00649f18（addステートメントに戻る）

一方、ケースロジックは単純に次のとおりです。

movzx eax、[edi]
sub ax、$ 01
jb $ 00649ef0
sub ax、$ 09
jz $ 00649ef0
sub ax、$ 03
jz $ 00649ef0
add edi、$ 02
jmp $ 00649ed6（movzxステートメントに戻る）

ケースロジックは非常に効率的なアセンブラを使用しているように見えますが、CharInSetステートメントは実際にはSysUtilsにあり、次のような単純なCharInSet関数を呼び出す必要があります。

関数CharInSet（C：AnsiChar; const CharSet：TSysCharSet）：ブール値;
結果の開始
：=CharSetのC;
終わり;

これが行われる唯一の理由は、[''、＃10、＃13、＃0]のP ^がDelphi2009で許可されなくなったため、呼び出しが型の変換を行って許可するためだと思います。

それにもかかわらず、私はこれに非常に驚いており、それでも私の結果を信頼していません。

AQTimeは何か間違ったものを測定していますか、この比較で何かが欠けていますか、それともCharInSetは本当に使用する価値のある効率的な関数ですか？

結論：

バリー、わかったと思う。時間を割いて詳細な例を示していただきありがとうございます。私は自分のマシンでコードをテストし、.171、.066、および.052秒を取得しました（私のデスクトップはラップトップよりも少し速いと思います）。

そのコードをAQTimeでテストすると、3つのテストで0.79、1.57、1.46秒になります。そこでは、計装からの大きなオーバーヘッドを見ることができます。しかし、私が本当に驚いたのは、このオーバーヘッドによって、見かけの「最良の」結果が、実際には最悪のCharInSet関数に変わることです。

したがって、Marcuは正しく、CharInSetは低速です。しかし、あなたはうっかりして（または意図的に）、CharInSetがSetメソッドのAnsiChar（P ^）で何をしているのかを引き出すことによって私にもっと良い方法を与えてくれました。ケース方式に比べて速度がわずかに優れていることを除けば、ケースを使用するよりもコードが少なく、理解しやすいです。

また、AQTime（および他のインストルメンテーションプロファイラー）を使用した誤った最適化の可能性についても認識しました。これを知っていると、Delphi用のプロファイラーとメモリ分析ツールに関する私の決定に役立ちます。また、 AQTimeはどのようにそれを行うのかという私の質問に対する別の答えでもあります。。もちろん、AQTimeはインストルメント時にコードを変更しないため、他の魔法を使用して変更する必要があります。

したがって、答えは、AQTimeが誤った結論につながる結果を示しているということです。

フォローアップ：AQTimeの結果が誤解を招く可能性があるという「告発」をこの質問に残しました。しかし、公平を期すために、この質問を読むように指示する必要があります。Delphiの高速GetTokenルーチンはありますか？これは、AQTimeが誤解を招く結果をもたらすと考え始めたものであり、そうではないと結論付けています。

モバイル デバイス (Windows Mobile 6.1) 用のプログラミングに必要なものと、使い慣れた IDE (RAD Studio 2009) を使用できるかどうかに興味があります。

Delphi または C++Builder のユーザーが学べるモバイル開発コミュニティはありますか?

ドライバー、メモリ制限、デバイス固有の考慮事項など、開発手法に違いはありますか?

ドキュメントとチュートリアルへのリンクは常に素晴らしいものです!

ありがとう！

IntToStr()関数は現在Unicodeである文字列を返します。に変換したいAnsiString。AnsiString(IntToStr(I))安全に使用できますか？