You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This optimization is to short-circuit the repeated search for and allocation of numerous CLRObjectMarshaller objects during UpdateRenderPackageAsyncTask execution. Right now, within UpdateRenderPackageAsyncTask, we call mirrorData.GetData() for every object we are attempting to tessellate. Within that call, a new instance of an ObjectMarshaller allocated based on the objects type information. This optimization caches the ObjectMarshaller and reuses it if the object type is the same for repeated calls.
saintentropy
changed the title
GraphicData provider ot
GraphicDataProvider optimization for repeated calls to get similar object types for tessellation
Aug 7, 2021
In a test graph with a lot of repeated calls to Circle.ByPointRadius this call reduced the time spent in this method from .5s to .07s and also reduced temporary memory allocation by 90%.
saintentropy
changed the title
GraphicDataProvider optimization for repeated calls to get similar object types for tessellation
DYN-4229 GraphicDataProvider optimization for repeated calls to get similar object types for tessellation
Oct 18, 2021
The reason will be displayed to describe this comment to others. Learn more.
They are static because you only need one Interpreter and FFIObjectMarshaller for the GraphicDataProvider class until the runtime is reset. If you made the instances you would allocate permanently an interpreter and marshaller for every mirror data object and that would be worse than temporary allocation
The reason will be displayed to describe this comment to others. Learn more.
I see that the graphicdataprovider member for mirrordata is static too so it looks like there will only be one instance of graphicdataprovider ever but I guess it doesn't hurt to make these static here as well.
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.
Purpose
https://jira.autodesk.com/browse/DYN-4229
This optimization is to short-circuit the repeated search for and allocation of numerous
CLRObjectMarshaller
objects duringUpdateRenderPackageAsyncTask
execution. Right now, withinUpdateRenderPackageAsyncTask
, we callmirrorData.GetData()
for every object we are attempting to tessellate. Within that call, a new instance of an ObjectMarshaller allocated based on the objects type information. This optimization caches the ObjectMarshaller and reuses it if the object type is the same for repeated calls.Declarations
Check these if you believe they are true
*.resx
filesReviewers
TBD
FYIs
@jasonstratton @QilongTang