perf: expose a reusable PolicySet to avoid re-parsing on every is_authorized call

[Iamrodos]

I’ve been profiling per-request cost in a Lambda-based service that uses cedarpy with a static, code-checked policy set, and the per-call PolicySet::from_str inside is_authorized is showing up as the dominant cost. On the same machine I’m seeing ~1 ms per call against a 16 KB policy file vs ~0.07 ms with a single-permit policy, so the parse really is most of the work.

Since cedar_policy::Authorizer::is_authorized already takes &PolicySet directly, I’m wondering whether you’d be open to exposing a Python-side PolicySet (e.g. PolicySet.from_str(...)) that is_authorized and is_authorized_batch could accept alongside str. So backwards compatible. Callers whose policies are static could then parse once and reuse the object for the lifetime of the process.

I would be happy to create a PR if there is interest.

[Iamrodos]

The handle would be opaque on the Python side and unwrap back to the real Rust &PolicySet with no copy when it crosses the FFI. This is the same technique pydantic-core uses with SchemaValidator: a schema is parsed and compiled once into a Rust-backed Python object, then reused for every validate_python(...) call.

[skuenzli]

@Iamrodos - thanks for opening an issue to discuss this.

Yes, I am open to enhancing is_authorized* to accept a PolicySet handle argument. I think we should also consider providing the same facility for entities.

What semantics have other bindings settled on?

cedar-java provides:

AuthorizationResponse isAuthorized(AuthorizationRequest request, PolicySet policySet, Set<Entity> entities) throws AuthException;

cedar-policy-rb provides similar:

response = authorizer.authorized(request
  , policy_set # CedarPolicy::PolicySet
  , entities # CedarPolicy::Entities
)

Would users need to release PolicySet and entities manually? Or does Python+Maturin take care of the garbage collection automatically?

[Iamrodos]

Agreed on extending the same treatment to entities — they have the same per-call parse cost and the same "often static or reused across calls" usage pattern, so a parallel Entities handle makes sense.

On semantics, I'd lean toward matching cedar-java / cedar-policy-rb: keep the existing is_authorized(request, policies, entities) shape, but accept either str or a typed handle for the policies and entities arguments. That keeps current callers unchanged and lets perf-sensitive callers opt in by constructing PolicySet.from_str(...) / Entities.from_json_str(...) once and passing the handle.

On lifecycle: no manual release needed. PyO3 exposes Rust structs as Python objects via #[pyclass], and the Rust Drop runs when the Python refcount hits zero — same pattern pydantic-core uses for SchemaValidator. Callers just hold the handle for as long as they want to reuse it and drop the reference when done.

I am traveling the next 4 weeks but if you are happy to wait I can do a first cut at the PR then.

[skuenzli]

Excellent. The proposed approach sounds good to me. is_authorized already uses unions for various parameters, so widening the union to handle types seems straightforward.

I suggest tackling it after you return from traveling as I will be traveling as well.

[skuenzli]

@geekphilosophy pointed me to the cedar-java impl of caching: cedar-policy/cedar-java#350

thanks Chris!