local vs external variables best practices

[Colin Doncaster]

Hi there -

I had a quick question about local vs external variables. To me it seems like external variables will slow down evaluation due to the map.find(var) as used in the example* ( though maybe there's a more efficient way of handling that ). Have other's who have implemented SeExpr in their apps limited the number of external variables or does the flexibility overshadow the optimization?

The docs also say these are standard variables

Image Variables
• $u, $v -texture coords (scalars)
• $Cs, Source image color (vector)
• $As, Source image alpha (scalar)
Surface Shading or Texturing Activities
• $Cs, Source image color (vector)
• $u, $v -texture coords (scalars)
• $P - surface point (vector). Note: $P is sampled from the Pref geometry (if available)
• $N - surface normal
• $objectId - per-surface unique object Id, typically a small integer
• $frame - current frame number

Would it be safe to assume that these should generally be local variables?

*I'm also assuming that map.find(var) is as slow as map[string] & map.count() but maybe I'm mistaken?

Cheers,
Colin

[brentb]

On Jun 30, 2:45 pm, Colin Doncaster <colin.doncas...@gmail.com> wrote:
> I had a quick question about local vs external variables.

You're not really meant to choose between the two. External variables
are values that are provided to the expression. Local variables are
values set by the expression. Both should be efficient.

>  To me it seems like external variables will slow down evaluation due to the map.find(var) as used in the example* ( though maybe there's a more efficient way of handling that ).

The map.find is part of resolveVar which is only called during
parsing. During eval, the cost of an external variable is only the
cost of a C++ virtual call (SeExprVarRef->eval()) and whatever the
implementation of the var does.

>  Have other's who have implemented SeExpr in their apps limited the number of external variables or does the flexibility overshadow the optimization?

There's negligible cost related to the number of external variables.
If you use a hash map as your var table during binding then you have
O(1) lookup cost, and you only pay that once during parse time anyway.

> The docs also say these are standard variables
>
> Image Variables
>         • $u, $v -texture coords (scalars)
>         • $Cs, Source image color (vector)
>         • $As, Source image alpha (scalar)
> Surface Shading or Texturing Activities
>         • $Cs, Source image color (vector)
>         • $u, $v -texture coords (scalars)
>         • $P - surface point (vector). Note: $P is sampled from the Pref geometry (if available)
>         • $N - surface normal
>         • $objectId - per-surface unique object Id, typically a small integer
>         • $frame - current frame number

These are the variable names that we try to keep consistent across our
in-house tools. SeExpr doesn't really care what variables you have
though.

> Would it be safe to assume that these should generally be local variables?

These are assumed to be external variables.

> *I'm also assuming that map.find(var) is as slow as map[string] & map.count() but maybe I'm mistaken?

For std::map, map.find is O(n log n), but again, this is only called
once per var, during parse.

Hope that helps,
Brent

[Colin Doncaster]

Thanks Brent,

I think I've misunderstood the intention of local vs. external and probably need to update how I've integrated SeExpr with user variables. In the example setX() and x are defined as local variables and used to pass that value to the expression but I guess using the renderman example might be a better reference?

Cheers

[Andrew Selle]

I think any of the examples I've packaged is relatively efficient with
their use of externals. But the renderman example shows a lot of the
best practices you might want to follow in sophisticated examples.
And feel free to ask more detailed questions, and we can share our
experience.

-Andy