xlat performance / "compile time" parsing?

[Alan DeKok]

Phil Mayers wrote:
> I've stared at the code for the first two a bit, and I think I
> understand why it's so expensive; it essentially parses the input string
> one character at a time, every time, and in the case of a conditional
> attribute, it walks over the input twice (or more).

  Well, that's an obvious place to fix things.

> A roughly similar thing happens wth radius_evaluate_condition.
> 
> This set me to wondering about some kind of parser cache. The idea would
> be that a string like:
> 
> "var %{%{foo}:-%{%{bar}:-baz}}"

  This could maybe be done for "unlang".  For other expansions, it's a
lot more difficult.

  My first priority would be to simplify the parsing of conditional
expansions.  If that helps, it's likely good enough.

> ...would be parsed into some kind of linked-list / tree, like so:

  Like a language...

> Before I embark on this to see if it helps - is this even a reasonable
> approach?

  Maybe.  I'm scared of any complex solution.  I'd much rather find out
what's wrong with radius_xlat, and go fix it.

  Alan DeKok.