You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The repeat parser repeats over a parser for bounded number of times, returning
the results as a list. It does have a slight overhead compared to known
execution times due to an anonmous function call, but that is necessary when
performing a dynamic number of repetitions without mutable variables.
A possible optimization would be to have some degree of "loop unrolling", if performance measuerements show it's helpful. The degree of unrolling could even be specified by the user, with a iterations_per_function_call parameter. For known maximum counts you could eliminate recursion completely (for a reasonably low number of maximum counts)
The text was updated successfully, but these errors were encountered:
A possible optimization would be to have some degree of "loop unrolling", if performance measuerements show it's helpful. The degree of unrolling could even be specified by the user, with a iterations_per_function_call parameter. For known maximum counts you could eliminate recursion completely (for a reasonably low number of maximum counts)
Hmm, that is possible. Perhaps an unroll of an inline call up to a user-specified max (with a trade-off of larger code generation) before it calls back to anonymous function calls. I'll leave this open to remind me for when I get time to put it in. Or feel free to PR it. :-)
You say that:
A possible optimization would be to have some degree of "loop unrolling", if performance measuerements show it's helpful. The degree of unrolling could even be specified by the user, with a
iterations_per_function_call
parameter. For known maximum counts you could eliminate recursion completely (for a reasonably low number of maximum counts)The text was updated successfully, but these errors were encountered: