Am 22. März 2012 00:19 schrieb sebb <seb...@gmail.com>:
> On 21 March 2012 19:16, Benedikt Ritter <benerit...@googlemail.com> wrote:
>> Hey,
>>
>> I've tried to remove the Token input parameter in CSVLexer.nextToken().
>> First by creating ne new Token on every invocation of nextToken().
>> That slowed execution of that method by about 100ms.
>
> 100ms per iteration? Or for the entire file?
>

for parsing the hole file

>> So I added a
>> private Token field to CSVLexer, that only get's initiated once. But
>> that solution was also slower than the one we have now.
>>
>> I'm not sure what to do now. Any suggestions? Shall I create a patch
>> for you to review?
>
> It's not necessary to change that call, so let's leave it.
>

It was plan of our plan to split up the parsing logic in smaller
methods to make it easier for the compiler to optimize the code. I
thought it may be easier if we got rid of that input parameter.

>> Regards,
>> Benedikt
>>
>> Am 16. März 2012 17:06 schrieb Emmanuel Bourg <ebo...@apache.org>:
>>> Le 16/03/2012 17:01, Emmanuel Bourg a écrit :
>>>
>>>
>>>>> 2. add additional convenience methods
>>>>> Right now we have some methods for char handling like isEndOfFile(c).
>>>>> There are some methods missing like isDelimiter(c) or
>>>>> isEncapsulator(c). There is not much to say about this. I just think
>>>>> that isDelimiter(c) is slightly easier to understand than c ==
>>>>> format.getDelimiter().
>>>
>>>
>>> Sorry I misread your phrase. Actually removing these methods resulted in a
>>> slower parsing. So yes give it a try.
>>>
>>>
>>> Emmanuel Bourg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to