Re^2: Speeds vs functionality

How much speed are you willing to sacrifice for a new feature?

As much as it takes, ’cause I need the damn feature! ☺

IMHO, a modern CSV parser must be able to parse Unicode text encoded in any Unicode character encoding scheme and with any arbitrary Unicode characters (code points, or even <gulp> extended grapheme clusters) used for CSV metacharacters. And it must properly handle the Unicode byte order mark as prescribed by the Unicode Standard.

I'm the monk responsible for these related posts and threads:

Best Way To Parse Concordance DAT File Using Modern Perl?
Peculiar Reference To U+00FE In Text::CSV_XS Documentation (especially this final post in the thread)
Re: Text::CSV and Unicode

In the case of the Concordance DAT file, the sep_char separator character, U+0014, is encoded in one byte in UTF-8: "\x14". It's the quote_char quote character (and consequently also the escape_char quote escape character), U+00FE, that happens to be encoded in two bytes in UTF-8: "\xC3\xBE".

Jim

Comment on Re^2: Speeds vs functionality Select or Download Code

Replies are listed 'Best First'.
Re^3: Speeds vs functionality by Tux (Canon) on Jul 30, 2014 at 12:13 UTC
If I am satisfied with `sep`, `quote_char` and maybe even `escape_char` will be the next to deal with. Even with the rewrite as suggested by salva (more or less) I still see a slowdown of close to 10%. Enjoy, Have FUN! H.Merijn	[reply] [d/l] [select]
Re^4: Speeds vs functionality by salva (Canon) on Jul 31, 2014 at 08:28 UTC
How are your benchmarking the code? I would like to try some ideas myself.	[reply]
Re^5: Speeds vs functionality by Tux (Canon) on Jul 31, 2014 at 08:41 UTC
`$ perl -Iblib/lib -Iblib/arch examples/speed.pl 5` [download] Enjoy, Have FUN! H.Merijn	[reply] [d/l]
Re^6: Speeds vs functionality by Anonymous Monk on Jul 31, 2014 at 08:45 UTC
Re^7: Speeds vs functionality by Tux (Canon) on Jul 31, 2014 at 08:48 UTC
Re^6: Speeds vs functionality by salva (Canon) on Jul 31, 2014 at 08:49 UTC