Conversation
|
This is obviously a byproduct of the cases in the benchmark, optimising the most obvious parts of the worst cases. Building a more diverse benchmarking dataset would help validate that the introduced penalty is worth it for most usage. |
|
Performance isn't the primary goal; did this change things a lot? FWIW the cases like |
|
The bench results are not very stable for me, but I see 15% performance improvement for some of them, and in my own workloads I see that scale of improvement but I havent done any timing yet. While the performance is nice, the primary driver for me is that I am trying to simplify the internal state of sre_yield so I can use it for post-processing. I've also got a fairly decent simplifier for the SRE parse tree at https://github.com/jayvdb/sre-tools/blob/develop/sre_tools/_simplify.py . It doesnt perform well yet. |
|
If you like, I can rebase this PR on top of #32 to show the changes to the internal structures to the baseline. |
0, 1, many principle for avoiding unnecessary instantiation of ConcatenatedSequence and CombinatoricsSequence which only act as placeholders. This improves the benchmark results, and the overhead of additional branches early performs well under typical workloads.
d095000 to
d8b8066
Compare
d8b8066 to
ab740ec
Compare
|
Rebased and repr tests updated to illustrate the internal structural simplification and its ramifications. |
0, 1, many principle for avoiding unnecessary instantiation of
ConcatenatedSequence and CombinatoricsSequence which only
act as placeholders.
This improves the benchmark results, and the overhead of additional
branches early performs well under typical workloads.