You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stefan Rufer <st...@netcetera.ch> on 2006/02/22 16:49:41 UTC
[csv] Priorisation of enhancements
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/~bayard/commons-csv/
IMO a possible priorisation of these tasks is:
1) naming/design
2) performance
3) features
Please let me know what you think or what your priorisation would look
like.
cu
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [csv] Priorisation of enhancements
Posted by Martin van den Bemt <ml...@mvdb.net>.
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 : as lightweight as possible.
Still not sure if our goals of commons-csv are a match though, so still in doubt if I should move
the stuff I did to my own cvs tree on mvdb.org..
Feedback appreciated..
Mvgr,
Martin
Henri Yandell wrote:
> On 2/22/06, Stefan Rufer <st...@netcetera.ch> 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 details of the tests and feature list see
>> http://people.apache.org/~bayard/commons-csv/
>>
>>IMO a possible priorisation of these tasks is:
>>
>>1) naming/design
>>2) performance
>>3) features
>
>
> 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 generator and
> making the assumption that it'll give us a performance improvement.
>
> Sorry for not replying to your previous emails; I'm right at the end
> of organizing a move to a new city, so my spare time has been
> demolished for the past few weeks.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [csv] Priorisation of enhancements
Posted by Stefan Rufer <st...@netcetera.ch>.
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 generator and
> making the assumption that it'll give us a performance improvement.
First guesses brought up that the current implementation can be optimized
quite a bit with a profiler. But of course we have to prove this with some
measure/optimize/measure cycles.
We'll look into this in the next weeks and give feedback here...
Of course: any hints welcome!
cu
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [csv] Priorisation of enhancements
Posted by Henri Yandell <fl...@gmail.com>.
On 2/22/06, Stefan Rufer <st...@netcetera.ch> 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 details of the tests and feature list see
> http://people.apache.org/~bayard/commons-csv/
>
> IMO a possible priorisation of these tasks is:
>
> 1) naming/design
> 2) performance
> 3) features
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 generator and
making the assumption that it'll give us a performance improvement.
Sorry for not replying to your previous emails; I'm right at the end
of organizing a move to a new city, so my spare time has been
demolished for the past few weeks.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org