Quote:
Originally Posted by davidfor
What about "raw_field()"? I probably use that as much as "field()".
|
For 'field' the overhead of invoking the formatter function was significant compared to what the function did (one attribute reference). This isn't true for raw_field, which deals adding separators to lists. I could still inline it but it wouldn't save much and could actually cost because I would need to add another 'if' in the main interpreter loop.
Currently the parser and the interpreter are the same code. I am considering building a separate parser and caching the parse tree. For composites and color rules this could increase performance by an order of magnitude. It would also permit me to do more inlining because the choice would be made at parse time, not execution time. The challenge is to do it without breaking anything.
I also wonder if it is worth it -- is performance with the improved interpreter (still) a problem?