My problem was the same.. Currently catching up.
I thing preformance is that last on the list. Premature optimization is most of the time a waste of
time and it is better to have a good API, which allows easy optimization...
My goal is the first shoot for a no dependency solution btw, in short :
On Wed, 22 Feb 2006, Henri Yandell wrote:
Given the slow performance of the current codebase, I'm tempted to
think that 2) should be moving in parallel with 1). Either by
hand-optimising the current one via a tool like YourKit or JProfiler;
or by leaping over to generating a parser via a parser g
On 2/22/06, Stefan Rufer <[EMAIL PROTECTED]> wrote:
> Henry proposed a series of enhancements for the commons-csv, including:
>
> - performance (poor for current implementation)
> - features
> - naming/design (introduce Csv instead of String[][], introduce
> CsvStrategy class)
>
> For det
Henry proposed a series of enhancements for the commons-csv, including:
- performance (poor for current implementation)
- features
- naming/design (introduce Csv instead of String[][], introduce
CsvStrategy class)
For details of the tests and feature list see
http://people.apache.org/~ba
