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.