Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Optimize compilation of expressions #1002

Closed
springmeyer opened this Issue · 4 comments

1 participant

@springmeyer
Owner

Currently all expressions are evaluated at runtime. But, as we plan to move to everything as expressions in #828, we need to ensure top performance. For example, if a polygon fill color moves to an expression we can then do: fill="[color]", which must be evaluated at runtime. But fill="rgb(100,100,255)" should be evaluated at parse time.

@springmeyer
Owner

it appears creating and destroying the grammer is a major bottleneck. Therefore we may also need to look at breaking up grammars, especially in the case where they cannot be easily re-used.

@springmeyer
Owner

initial work started in c++11 branch at 75aa6e9

@springmeyer springmeyer referenced this issue from a commit
@artemp artemp + expression_optimizer (experimental)
at the moment very basic ops are supported e.g

```
expr = 1+1+1 ---> expr = 3
expr = 1+1+[ATTR] ---> 2+[ATTR]

expr = [ATTR] + 1 + 1  ---> ([ATTR] + 1) + 1  ### stays unchaged
expr = [ATTR] + 1/3.14159 + 1 ---> ([ATTR] + 0.31831) + 1
```
75aa6e9
@ajashton ajashton referenced this issue in mapbox/tilemill
Closed

Can't use expressions to set line-width #2040

@springmeyer
Owner

working code stashed at https://gist.github.com/springmeyer/6618336 for now and removed from c++11 branch to make merging cleaner.

@springmeyer
Owner

pre-evaluation is now happening. Next step is to more aggressively pre-eval by type so we can throw at load_map when the type is bound to be invalid. Tracking that at #2237

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.