Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #725
| From | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: lexer speed, was Bison |
| Date | 2012-08-20 01:01 +0100 |
| Organization | Compilers Central |
| Message-ID | <12-08-008@comp.compilers> (permalink) |
| References | <12-08-005@comp.compilers> <12-08-006@comp.compilers> |
> [Compilers spend a lot of time in the lexer, because that's the only > phase that has to look at the input one character at a time. -John] When the source code resides in a memory buffer, the time for reading e.g. the characters of an identifier (in the lexer) is neglectable vs. the time spent in lookup and entering the identifier into a symbol table (in the parser). Even if a lexer reads single characters from a file, most OSs maintain their own file buffer, so that little overhead is added over the program-buffered solution. I really would like to see some current benchmarks about the behaviour of current compilers and systems. DoDi [The benchmarks I did were a while ago, but they showed a large fraction of time in the lexer. I wouldn't disagree that building the symbol table is slow, but figure out some estimate of the ratio of the number of characters in a source file to the number of tokens, and that is a rough estimate of how much slower the lexer will be than the parser. I agree that some current analyses would be useful. -John]
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support hsad005@gmail.com - 2012-08-17 11:22 -0700
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-18 10:13 +0100
Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-20 01:01 +0100
Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-20 16:14 +0100
Re: lexer speed, was Bison BGB <cr88192@hotmail.com> - 2012-08-20 14:14 -0500
Re: lexer speed, was Bison Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2012-08-21 07:40 +0100
Re: lexer speed, was Bison "BartC" <bc@freeuk.com> - 2012-08-21 17:39 +0100
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-20 13:35 +0000
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support BGB <cr88192@hotmail.com> - 2012-08-21 14:45 -0500
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support "BartC" <bc@freeuk.com> - 2012-08-22 14:04 +0100
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support BGB <cr88192@hotmail.com> - 2012-08-26 19:37 -0500
Bison deterministic LALR parser for Java/C++ "BartC" <bc@freeuk.com> - 2012-08-29 22:03 +0100
speeding up C recompilation, was Re: Bison deterministic LALR BGB <cr88192@hotmail.com> - 2012-09-04 13:45 -0500
Re: C include handling, was Bison deterministic LALR Marco van de Voort <marcov@toad.stack.nl> - 2012-09-05 08:40 +0000
Re: Bison deterministic LALR(1) parser for Java/C++ (kind of complex langauge) without 'lexar hack' support hsad005@gmail.com - 2012-08-18 02:09 -0700
csiph-web