Re: [Flex-help] Generated scanner consumes too much time - help request
flex is a tool for generating scanners
Brought to you by:
wlestes
From: Will E. <wes...@gm...> - 2018-03-16 21:05:36
|
I don't think the one open pull request against 2.6.5 will effect the performance you're seeing, so just see how your scanner does against whatever the tip of master happens to be. On Friday, 16 March 2018, 10:01 pm +0100, Simon Sobisch <sim...@gn...> wrote: > Thank you for answering and about the notes about the progress. > > I'll try 2.6.5 dev on Monday or Tuesday (or whenever the pull you > refered to was done) - Can you please leave a link to the PR allowing me > to subscribe to it? > I'll report back next week when I have access to the test environment. > > If someone stumbles over bad practice in the referred scanner.l I'd > still like to know about it ;-) > > Thank you for the analyzer, > Simon > > Am 16.03.2018 um 21:32 schrieb Will Estes: > > There have been some performance changes since that version, yes, so first I would see how things stand with 2.6.4. There will be a 2.6.5 soonish -- one more pull request remains and then I'll be putting in tooling in to make releasing flex easier -- just to give you a sense of the timeline for 2.6.5 which also contains a fair number of changes since 2.6.4. > > > > On Friday, 16 March 2018, 9:05 pm +0100, Simon Sobisch <sim...@gn...> wrote: > > > >> > >> Hi flex-users and developers, > >> > >> I've just did a profiling (using callgrind) on the GnuCOBOL compiler > >> (parsing only) with 2,500,000 LOC and found out that the recent > >> scanner[1] consumes most of the time: > >> > >> * 44% spent in yylex (16% of these are spent in GnuCOBOL internal > >> functions leaving 28% of the complete parser process in this single flex > >> generated file) > >> > >> * 13% in yy_get_previous_state > >> > >> * 5.6% spent in yy_get_next_buffer with 1.3% in fgets > >> > >> Removing all the "noise" there is still over 25% spent in the scanner > >> and "get_previous_state" doesn't sound like it should be called that often. > >> > >> I guess there are some bad practices used in scanner.l, but I don't know > >> what to look out for. > >> Can you please have a look at this and post suggestions or point to bad > >> practice found in there? > >> > >> Is the amount of calls to get_previous_state normal? > >> > >> scanner.c was generated with flex 2.5.37 - Do you expect a speedup with > >> a more recent release? > >> > >> Thank you for taking the time to answer and maybe even for checking the > >> source, > >> Simon > >> > >> [1] https://sourceforge.net/p/open-cobol/code/HEAD/tree/trunk/cobc/scanner.l > >> > >> ------------------------------------------------------------------------------ > >> Check out the vibrant tech community on one of the world's most > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > >> -- > >> Flex-help mailing list > >> Fle...@li... > >> https://lists.sourceforge.net/lists/listinfo/flex-help > > -- Will Estes wes...@gm... |