Related articles |
---|
The case of directly-executable parsers momchil.velikov@gmail.com (2006-01-28) |
Re: The case of directly-executable parsers derek@_NOSPAM_knosof.co.uk (Derek M. Jones) (2006-01-28) |
Re: The case of directly-executable parsers momchil.velikov@gmail.com (momchil.velikov@gmail.com) (2006-01-30) |
Re: The case of directly-executable parsers clint@0lsen.net (Clint Olsen) (2006-01-31) |
Re: The case of directly-executable parsers rmathew@gmail.com (Ranjit Mathew) (2006-01-31) |
Re: The case of directly-executable parsers 148f3wg02@sneakemail.com (Karsten Nyblad) (2006-01-31) |
Re: The case of directly-executable parsers momchil.velikov@gmail.com (momchil.velikov@gmail.com) (2006-02-02) |
From: | Clint Olsen <clint@0lsen.net> |
Newsgroups: | comp.compilers |
Date: | 31 Jan 2006 00:35:48 -0500 |
Organization: | Compilers Central |
References: | 06-01-104 06-01-109 06-01-116 |
Keywords: | parse, performance |
Posted-Date: | 31 Jan 2006 00:35:48 EST |
On 2006-01-30, momchil.velikov@gmail.com <momchil.velikov@gmail.com> wrote:
> I have also implemented a kind of a "switch optimizer". After removing
> the most frequent transition, the keys are separated in "dense" ranges,
> where density threshold is a parameter (say, 0.33 or 0.5). Then a linear
> or a binary search is performed depending on the number of ranges (say >=
> 8 binary search, otherwise - linear).
>
> This did not result in any performance gain, although it did reduce the
> code size by a decent amount.
The authors of re2c did fiddle around with the binary search in some
circumstances, and they discuss this in the accompanying LOPLAS
article that comes with the source. However, their conclusions might
be somewhat dated. I seem to recall they had different results using
if/else blocks vs. switch statements. Re2c appears to have a new
maintainer:
http://re2c.org
-Clint
Return to the
comp.compilers page.
Search the
comp.compilers archives again.