On 22 March 2012 10:40, sebb <seb...@gmail.com> wrote: > On 22 March 2012 07:33, Benedikt Ritter <benerit...@googlemail.com> wrote: >> 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 > > I see a bigger slowdown when testing just the lexer. > >>>> 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. > > OK, I see. >
I think the lexer is now somewhat simpler (and is much faster). >>>> 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 >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
