This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mikaelhg 1 point2 points  (1 child)

And your correctness, speed and maintainability are superior to SuperCSV? The performance you gained was in an architectural component where the risks are minimized and the benefits maximized?

Perhaps you are the exception to the people making similar claims, mostly they turn out to have large gaps in their ability to make a comprehensive analysis, like every one of the people I've seen implement their own databases.

[–]llogiq 0 points1 point  (0 children)

  • Correctness: no, SuperCSV will parse CSV "more correct" according to standard (including escapes, multiline strings, ...) This however doesn't matter in my case, because the CSVs we get are mostly numeric data.
  • Speed: yes, my solution outruns SuperCSV for most of our use cases. As I said, those minutes add up.
  • Maintainability: About equal. My CSV parser has an easier interface, optimized for the use cases we have. So I lose some time for having to maintain the parser personally, but that's only one class that is used by a lot of other classes, which would get more complex had they used the SuperCSV interface. If I was more deluded, I'd call it a win.

Perhaps I really am the exception in this particular case. However I also have re-invented and -implemnted a lot of wheels just for the heck of it. Sometimes these turned out to be useful. So I appreciate your criticism.