perf: cache traced field conversion #2976
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Greptile Overview
Updated On: 2025-11-07 12:55:45 UTC
Greptile Summary
Adds
_has_tracerscache to optimize tracer field conversion by short-circuiting when objects have no autograd tracers.Major changes:
_has_tracersprivate attribute to cache tracer presence status_strip_traced_fields()to set cache and return early when no tracers existto_static()to leverage cache for performancestarting_pathparameter (tuple[str, ...]instead oftuple[str])copy()methodCritical issue found:
_has_tracerscache is object-level but_strip_traced_fields()accepts astarting_pathparameter to check only a subset of the objectConfidence Score: 1/5
_strip_traced_fields()is called with differentstarting_pathvalues, which happens in the autograd workflow (e.g.,starting_path=("structures",)andstarting_path=("data",)). The bug is deterministic and will affect correctness of autograd operations.tidy3d/components/base.pyneeds to be redesigned to either track cache per-path or avoid caching for path-specific queriesImportant Files Changed
File Analysis
_has_tracerscache for performance but has critical logic bug where object-level cache is used incorrectly for path-specific queries, causing incorrect results when differentstarting_pathvalues are usedSequence Diagram
sequenceDiagram participant Client participant BaseModel as Tidy3dBaseModel participant Cache as _has_tracers cache Note over Client,Cache: Scenario 1: Initial check with no path Client->>BaseModel: to_static() BaseModel->>BaseModel: _strip_traced_fields() BaseModel->>BaseModel: handle_value() recursively alt No tracers found BaseModel->>Cache: _has_tracers = False BaseModel->>Client: return self (early exit) else Tracers found BaseModel->>Cache: _has_tracers = True BaseModel->>BaseModel: get_static() on fields BaseModel->>BaseModel: _insert_traced_fields() BaseModel->>Cache: static_self._has_tracers = False BaseModel->>Client: return static_self end Note over Client,Cache: Scenario 2: Check with starting_path Client->>BaseModel: _strip_traced_fields(starting_path=("structures",)) alt _has_tracers is False Note over BaseModel,Cache: BUG: Returns early even though<br/>cache is for full object, not this path BaseModel->>Client: return dict_ag() (incorrect!) else _has_tracers is None or True BaseModel->>BaseModel: self.dict()[starting_path] BaseModel->>BaseModel: handle_value() on subset alt Field mapping found BaseModel->>Cache: _has_tracers = True (incorrect for path-specific!) BaseModel->>Client: return dict_ag(field_mapping) else No mapping Note over BaseModel,Cache: Cache not updated for path-specific check BaseModel->>Client: return dict_ag() end end