Trajectory datavec now cached during NLP obj/jac/hess assembly callbacks, leaving only constant allocation overhead

[gennadiryan]

DTO Evaluator cache refactor — PR summary

What changed

_update_trajectory_cache! in DirectTrajOpt.jl/src/solvers/evaluator.jl was constructing a fresh NamedTrajectory on every MOI callback (objective, gradient, constraints, Jacobian, Hessian — 5-8 calls per Ipopt iteration). Each construction triggered the full copy-constructor → inner-constructor chain in NamedTrajectories.jl, which re-derives dims, names, states, bounds (via an OrderedDict round-trip), and global metadata from scratch — ~10-12 allocations per call, all redundant since only datavec and global_data change between calls.

The fix adds a single _cached_traj::NamedTrajectory field to the Evaluator struct, built once at construction with owned Vector{Float64} copies of datavec and global_data. On each callback, _update_trajectory_cache! now does copyto! into these buffers instead of constructing a new struct. All structural metadata (components, dims, bounds, N, etc.) is shared with prob.trajectory and never recomputed.

Why it's safe

Investigation confirmed that every downstream consumer of the returned traj — all integrator evaluate! / eval_jacobian / eval_hessian_of_lagrangian methods, all constraint evaluate! / eval_jacobian methods, all objective objective_value / gradient! methods — uses traj purely as a read-only data accessor. None store, alias, or compare it by identity. Views via traj[k] are re-derived from traj.datavec on each access (no stale views across callbacks). Full trace in evaluator-cache-analysis.md.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!