RE: performance bottleneck in yy_get_next_buffer function

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 bu=
ffer was resizing and it improved the performance significantly.

-regards
Gautam

-----Original Message-----
From: [email protected] [mailto:help-flex-bou=
[email protected]] On Behalf Of Gautam Kapoor
Sent: Tuesday, January 15, 2013 2:27 PM
To: Hans =C5berg
Cc: [email protected]
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 co=
uld be fixed by changing the buffer size. I have to try that. If one can ch=
oose an optimal buffer size (may not always be possible), then the effect o=
f this for-do will be minimized.

-regards
Gautam

-----Original Message-----
From: Hans =C5berg [mailto:[email protected]] =

Sent: Thursday, January 10, 2013 5:00 AM
To: Gautam Kapoor
Cc: [email protected]
Subject: Re: performance bottleneck in yy_get_next_buffer function

On 9 Jan 2013, at 18:20, Gautam Kapoor <[email protected]> wrote:

> I want to discuss a particular performance issue and how I tried to fix i=
t. I am wondering why it is not part of the default scanner generated by fl=
ex because I think the developers must have seen this too.

Flex is currently not developed or maintained, it seems. But a known proble=
m is that rules that capture a lot of input slows the lexer down. So, for e=
xample, scanning for a comment spanning several lines is better done line b=
y line.

Does your patch fix that problem?

Hans