efficient event execution on prefix lookup #60
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'd been meaning to try this to see what the implementation looked like. Annoying that it requires that recursive function to build the match spec, matchspec should have some sort of operation that lets you specify something is a prefix or
EventName ++ ['$tail']
that results in the match being a tail and not a single element... but I digress.I'd be curious in benchmarks. I'm not really expecting this to be accepted but I thought it better to actually do the comparison instead of assuming we can't do it.
My understanding was that the original attempt at doing prefix matching was still using a bag? Meaning it was scanning the whole table, so particularly slow. In this version I get around needing a bag by appending the handler id to the event name, doesn't change the lookup since it is a prefix lookup.
Or was the original attempt also an
ordered_set
and still proved to be far too inefficient to be viable?