22

データ型Data.Textを使用することの長所と短所を説明できる人はいますか? Data.ByteString.Char8ASCII のみのテキストを操作すると、これらの長所と短所が変わりますか? 彼らの怠惰な変種もストーリーを変えますか?

4

1 に答える 1

30

Data.ByteString.Char8ByteStringは、値を 8 ビット ASCII 文字のシーケンスとして扱う関数を提供しますData.Textが、Unicode 全体をサポートする独立した型です。

ByteStringText表現に関する限り、本質的に同じです—厳密なチャンクのリストに基づく遅延バリアントを含む、厳密なボックス化されていない配列。主な違いは、UTF-16 でエンコードされたByteStringオクテット (つまりWord8s) をText格納する一方で、s を格納することです。Char

ASCII のみのテキストで作業している場合、 を使用したData.ByteString.Char8方がおそらく より高速でText、メモリの使用量が少なくなります。ただし、ASCII のみを使用することが本当に確実かどうかを自問する必要があります。基本的に、99% のケースでData.ByteString.Char8overを使用するTextのはスピード ハックです — オクテットは文字ではありません。Haskellerなら誰でも、生のベアメタル速度よりも正しい型を使用することを優先すべきであることに同意できます。通常は、プログラムのプロファイリングを行い、それがボトルネックである場合にのみ考慮する必要があります。Textは十分に最適化されており、ほとんどの場合、その差はおそらく無視できます。

もちろん、速度に関係なくData.ByteString.Char8保証される状況もあります。テキストではなく基本的にバイナリ データであるが、複数の行に分割されたデータを含むファイルを考えてみましょう。使用linesは完全に合理的です。さらに、整数がバイナリ形式のコンテキストで ASCII 10 進数にエンコードされる可能性があることは完全に考えられます。その場合、使用readIntは完全に理にかなっています。

だから基本的に：

  1. Data.ByteString.Char8: パフォーマンスが最優先される純粋な ASCII の状況で、一部の ASCII コンポーネントを含む「ほぼバイナリ」のデータを処理する場合。
  2. Data.Text: テキスト。ASCII 以外が使用されている可能性がわずかにある状況を含みます。
于 2012-01-18T19:34:11.527 に答える