2012-01-18 12 views
20

誰もがData.TextData.ByteString.Char8のデータ型を使用して長所と短所を説明できますか? ASCIIのみのテキストで作業すると、これらの長所と短所が変わるのですか?彼らの怠惰な変種も話を変えますか?Data.TextとData.ByteString.Char8

答えて

28

Data.ByteString.Char8は、ByteStringの値を8ビットASCII文字のシーケンスとして扱い、Data.Textは、Unicode全体をサポートする独立型です。

ByteStringおよびTextは厳密な塊のリストに基づく遅延型の厳密で非ボックス化された配列である限り、基本的に同じです。主な違いは、ByteStringがオクテット(つまりWord8秒)を格納し、TextCharを格納し、UTF-16でエンコードされていることです。

ASCIIのみのテキストを使用している場合は、Data.ByteString.Char8を使用すると、おそらくTextより速くなり、メモリを少なくします。しかし、であるかどうかは、実際にはであるかどうかを確認する必要があります。基本的には、例99%で、TextData.ByteString.Char8を使用すると、スピードハックです - オクテット文字はなく、任意のHaskellerは正しいタイプを使用して、生の、ベアメタルスピードよりも優先されなければならないことに同意することができます。あなたがプログラムをプロファイリングしてボトルネックになっているのであれば、通常はそれを考慮する必要があります。 Textは最適化されており、ほとんどの場合、その差はごくわずかです。

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

だから、基本的には:

  1. Data.ByteString.Char8:パフォーマンスが重要であり、いくつかのASCII成分を有する「ほとんどバイナリ」のデータを処理するために、純粋なASCIIの状況では。
  2. Data.Text:テキスト(を含む) ASCII以外のものが少し使用される可能性がある状況。
+0

私のプログラムは非常に特定のコンピュータ生成のCファイルを処理するので、ASCIIのみのテキストがあることを保証できます。私はどちらの場合でも両方を試してみます。 –

+0

私はおそらく 'Data.ByteString.Char8'のために行くでしょう、あなたは本質的には*テキストに似ているバイナリフォーマットを扱うことになるでしょう。 (また、ファイルを解析するために[attoparsec](http://hackage.haskell.org/package/attoparsec)をチェックすることをお勧めします)。 – ehird

+0

テキストは、UTF-16とByteStringをオクテットとしてエンコードします。これは一般的にメモリ使用量に影響しますか?私のアプリケーションはコードリライタであり、それはそのままで、Stringを使ってトレースできる膨大な量のメモリを使います。私はすでに弦を演奏しているので、どんな改善も歓迎されるだろう。これが私がデータ型を変更したい理由です。 –

関連する問題