-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache usdz archive traversal for subsequent lookup/queries on external references. #1578
Cache usdz archive traversal for subsequent lookup/queries on external references. #1578
Conversation
8ef1053
to
2d30f0e
Compare
Filed as internal issue #USD-6817 |
Just wanted to mention I'm looking at merging this PR in now. Thanks for your patience! |
Thanks for your patience. I ended up reworking some of these changes and separating the fix for #1577 and #1579 into different commits. I also pulled the performance test into an internal test suite instead of committing them, as I'm hesitant to add a semi-large-ish file to the repo. We could certainly revisit that if necessary. I'm going to close this PR out in favor of those separate commits, which will land with the next dev push. Thanks again! |
…l references. The idea for this change and the initial implementation were contributed by @marsupial in PR #1578. I did some further simplifications, cleanup to conform to our standard style, and added a C++ unit test to exercise iterator behavior. From the original submission: While linearly traversing the **usdz** archive, cache the path and header information so that subsequent lookups can be accelerated. This brings down load time of a **usdz** file that was taking ~3 minutes to ~16 seconds, and can often wind up performing better than parsing the original **usdc** file that generated the **usdz** (likely because IO is avoided on the references as the files are _in memory_ from the archive). Fixes #1577 (Internal change: 2205950)
where default-constructed structs may incorrectly be detected as valid if their signature field happened to be initialized with a value that matched the expected signature. This initial fix for this issue was provided by @marsupial in PR #1578. Fixes #1579 (Internal change: 2206828)
…l references. The idea for this change and the initial implementation were contributed by @marsupial in PR PixarAnimationStudios#1578. I did some further simplifications, cleanup to conform to our standard style, and added a C++ unit test to exercise iterator behavior. From the original submission: While linearly traversing the **usdz** archive, cache the path and header information so that subsequent lookups can be accelerated. This brings down load time of a **usdz** file that was taking ~3 minutes to ~16 seconds, and can often wind up performing better than parsing the original **usdc** file that generated the **usdz** (likely because IO is avoided on the references as the files are _in memory_ from the archive). Fixes PixarAnimationStudios#1577 (Internal change: 2205950)
where default-constructed structs may incorrectly be detected as valid if their signature field happened to be initialized with a value that matched the expected signature. This initial fix for this issue was provided by @marsupial in PR PixarAnimationStudios#1578. Fixes PixarAnimationStudios#1579 (Internal change: 2206828)
Description of Change(s)
While linearly traversing the usdz archive, cache the path and header information so that subsequent lookups can be accelerated.
Fixes Issue(s)
#1577, #1579
This brings down load time of a usdz file that was taking ~3 minutes to ~16 seconds, and can often wind up performing better than parsing the original usdc file that generated the usdz (likely because IO is avoided on the references as the files are in memory from the archive).
The test case is an example that takes more than 15 seconds to load currently, but with caching goes down to 2 seconds. It has 25000 entries, chosen to demonstrate the time difference in a way that can be tested against regression. The amount of entries is also good to test against any race conditions filling in the cache (though per the comments in code, a relatively simplistic filling is used to as it performs well enough and keeps the code simple)