Just to update everyone, I did play around with increasing the sizes of YY_BUF_SIZE and YY_READ_BUF_SIZE. This helped me reduce the number of times buffer was resizing and it improved the performance significantly.
-regards Gautam -----Original Message----- From: help-flex-bounces+gkapoor=cadence....@gnu.org [mailto:help-flex-bounces+gkapoor=cadence....@gnu.org] On Behalf Of Gautam Kapoor Sent: Tuesday, January 15, 2013 2:27 PM To: Hans Åberg Cc: help-flex@gnu.org Subject: RE: performance bottleneck in yy_get_next_buffer function Hi Hans, This is true both for flex and flex++. Yes, my patch fixed that problem. Ideally, I would expect memcpy to be used instead of a for-do there. But Martin (attached email) suggests that it could be fixed by changing the buffer size. I have to try that. If one can choose an optimal buffer size (may not always be possible), then the effect of this for-do will be minimized. -regards Gautam -----Original Message----- From: Hans Åberg [mailto:hans.aber...@telia.com] Sent: Thursday, January 10, 2013 5:00 AM To: Gautam Kapoor Cc: help-flex@gnu.org Subject: Re: performance bottleneck in yy_get_next_buffer function On 9 Jan 2013, at 18:20, Gautam Kapoor <gkap...@cadence.com> wrote: > I want to discuss a particular performance issue and how I tried to fix it. I > am wondering why it is not part of the default scanner generated by flex > because I think the developers must have seen this too. Flex is currently not developed or maintained, it seems. But a known problem is that rules that capture a lot of input slows the lexer down. So, for example, scanning for a comment spanning several lines is better done line by line. Does your patch fix that problem? Hans _______________________________________________ help-flex mailing list help-flex@gnu.org https://lists.gnu.org/mailman/listinfo/help-flex
