There are several places where we repeat calls to -[WebAccessibilityObjectWrapperMac attachmentView] in close succession rather than storing the attachment view in a local variable and re-using it. This is wasteful in ITM as each call requires a separate, synchronous round-trip to the main-thread.
<rdar://problem/106584475>
Created attachment 465390 [details] Patch
Comment on attachment 465390 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=465390&action=review > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:3830 > + } I think we can get rid of the isAttschment variable and just use whether attachmentView is nil AddObject: attachmentView ?: wrapper
Created attachment 465391 [details] Patch
(In reply to chris fleizach from comment #3) > Comment on attachment 465390 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=465390&action=review > > > Source/WebCore/accessibility/mac/WebAccessibilityObjectWrapperMac.mm:3830 > > + } > > I think we can get rid of the isAttschment variable and just use whether > attachmentView is nil > > AddObject: attachmentView ?: wrapper Good point, thanks! Fixed in latest patch.
commit-queue failed to commit attachment 465391 [details] to WebKit repository. To retry, please set cq+ flag again.
(In reply to Tyler Wilcock from comment #4) > Created attachment 465391 [details] > Patch Would it make sense to get rid of isAttachment() and just have a attachmentView() that returns nil when it is not an attachment?
(In reply to Andres Gonzalez from comment #7) > (In reply to Tyler Wilcock from comment #4) > > Created attachment 465391 [details] > > Patch > > Would it make sense to get rid of isAttachment() and just have a > attachmentView() that returns nil when it is not an attachment? Yes, that's a good idea! Will put on my to-do list for a future patch.
Committed 261641@main (f238a7ef7870): <https://commits.webkit.org/261641@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 465391 [details].