Skip to content

Cleanup a change to ExecutionFrame a little - #7576

Merged
skottmckay merged 3 commits into
masterfrom
skottmckay/CleanupExecutionFrameOutputValidation
May 6, 2021
Merged

Cleanup a change to ExecutionFrame a little#7576
skottmckay merged 3 commits into
masterfrom
skottmckay/CleanupExecutionFrameOutputValidation

Conversation

@skottmckay

Copy link
Copy Markdown
Contributor

Description:
Reduce the binary size growth from #7252. Minimal build grew by 7KB from the checkin of those changes.

Firstly simplify the checking logic a little. Same checks are still done - just without using an extra layer of helpers.

The issue being addressed by the original change only applies if you have a graph output where the shape wasn't able to be inferred. e.g. Reshape node with dynamic input causes downstream shapes to be unknown. If that is not the case, MergeShapeInfo in graph.cc would have resolved any differences between a specified output shape and the inferred output shape during Graph::Resolve.

The issue does not apply to the execution frame used by the optimizer as the only time it would create a graph output is if it could constant fold all the way through, so MergeShapeInfo would have handled any difference in that case as well.

Due to these considerations, wiring a logger in at the IExecutionFrame level isn't necessary if VerifyOutputSizes optionally overridden by an implementation that cares.

Motivation and Context
Primarily to reduce binary size growth.
Avoid adding logger at the IExecutionFrame level when that is only needed in a derived class.

… 7KB from this checkin.

Firstly simplify the checking logic a little. Same checks are still done - just without using an extra layer of helpers.

The issue being addressed by the original change only applies if you have a graph output where the shape wasn't able to be inferred. e.g. Reshape node with dynamic input causes downstream shapes to be unknown. If that is not the case, MergeShapeInfo in graph.cc would have resolved any differences between a specified output shape and the inferred output shape during Graph::Resolve.

The issue does not apply to the execution frame used by the optimizer as  the only time it would create a graph output is if it could constant fold all the way through, so MergeShapeInfo would have handled any difference in that case as well.

Due to these considerations, wiring a logger in at the IExecutionFrame level isn't necessary if VerifyOutputSizes optionally overridden by an implementation that cares.
@skottmckay
skottmckay requested a review from sumitsays May 5, 2021 05:56
@skottmckay
skottmckay requested a review from a team as a code owner May 5, 2021 05:56
@skottmckay
skottmckay requested a review from fdwr May 5, 2021 05:56
@skottmckay

Copy link
Copy Markdown
Contributor Author

Binary sizes from minimal build

Starting size: 1129698
With original change: 1135554 (+7567 vs starting size)
With these changes: 1131106 (+1408 vs starting size)

pranavsharma
pranavsharma previously approved these changes May 5, 2021
Comment thread onnxruntime/core/framework/execution_frame.cc Outdated
Comment thread onnxruntime/core/framework/execution_frame.cc Outdated
@skottmckay
skottmckay merged commit 097bab8 into master May 6, 2021
@skottmckay
skottmckay deleted the skottmckay/CleanupExecutionFrameOutputValidation branch May 6, 2021 09:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants