MAYA106075 - Introducing color cache to improve performance #2059
Conversation
…::GetSelectionHighlightColor and ProxyRenderDelegate::GetCurveDefaultColor
| curveColorResult); | ||
| // Enter the mutex and check the cache | ||
| std::lock_guard<std::mutex> mutexGuard(_mayaCommandEngineMutex); | ||
| if (_dormantCurveColorCache.second == _frameCounter) { |
There was a problem hiding this comment.
I think if we make _dormantCurveColorCache.second a std::atomic<uint64_t> then we could move acquiring the mutex to be after this check to see if we already have already read the value this frame. That would prevent lots of mutex acquires which might be faster.
In the case where the test fails we'd have to acquire the mutex and re-test to avoid reading the value two or more times, but that is okay.
There was a problem hiding this comment.
The std::atomic<uint64_t> approach may be faster but not necessarily. We can try it if we still need to after this change.
| // Enter the mutex and check the cache | ||
| std::lock_guard<std::mutex> mutexGuard(_mayaCommandEngineMutex); | ||
| if (colorCache->second == _frameCounter) { | ||
| return colorCache->first; |
There was a problem hiding this comment.
Could use a similar lock-free pattern here.
|
I haven't tested the performance on a large scene. I have none at the moment. I only tested my custom scenes and confirmed that the feature is working as expected. |
vlasovi
added
the
ready-for-merge
… access attempts to the mutex.
Introducing color cache to improve performance of ProxyRenderDelegate::GetSelectionHighlightColor and ProxyRenderDelegate::GetCurveDefaultColor.
Make sure the cache is accessed from inside the mutex to prevent races.