-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-implement selectors as filters #343
Comments
I'm good with a reimplementation to turn them into filters. The hard part is implementing selector operations (adding/removing selectors, etc). As a sidenote, I may have mentioned this before, I've been thinking about a way to hijack random selectors in order to force a random outcome to select something specific. eg. |
Sounds good, I'll take a stab at doing this.
|
We wouldn't want it to fail. |
But then you won't catch improper use of |
Yeah that's completely fine. |
I'm going to test it but those set operations will be far from free. A 3-way And requires 5 function calls per tested entity. |
@djkaty @jleclanche
While we're on the topic of selector optimizations, right now the reason the selectors build up lists of entities and tear them down again is because while most selectors are just simple filters on entities, there are some that aren't, such as
FuncSelector
andRandomSelector
.This sucks, because what I'd like to do is simply (pseudo-code follows):
and so set operations are basically free:
No intermediate lists at all. As a first guess, this will lead to at least a 2-3x speedup, because selectors like
FRIENDLY_MINIONS
do at least 2x the work.This will require changing the DSL a bit though -- thoughts?
The text was updated successfully, but these errors were encountered: