Fork me on GitHub
#clara
<
2017-09-30
>
souenzzo01:09:06

Does "query" is a slow operation? For lage sets, witch shoud be optimal? - One big query with "all"(possible) facts, with some "garbage" and use just what I really need - Many little query, with just what I really need,

wparker04:10:16

Queries are really just rules without a RHS, at least in the current implementation. There are some optimizations that could be done on queries that aren’t valid for rules; for my part none of my use-cases have yet had enough of a problem to warrant spending the time implementing them. Note that the results are calculated during fire-rules, and calling “query” is really just a map get operation. Filters that can be expressed as values of bindings can end up being expressed as just map gets if the query parameters are set appropriately. Otherwise, to be honest its hard to say much about perf without knowing more specifics. My personal bias would be to express as much as possible in declarative logic e.g. “little queries” and then address any concrete perf problems that come up, but obviously the optimal strategy depends a lot on your use-case.