[Webkit-unassigned] [Bug 109597] Cache timer heap pointer to timers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Feb 13 06:18:22 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=109597





--- Comment #5 from Antti Koivisto <koivisto at iki.fi>  2013-02-13 06:20:36 PST ---
(In reply to comment #4)
> (From update of attachment 187896 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=187896&action=review
> 
> It is worrisome that these functions are so incredibly hot that TLS access - a very fast operation - shows up on the profile.

Part of the problem was that timerHeap() is accessed from many places during a singe call. Here is the profile before the patch:

Running Time    Self        Symbol Name
134.0ms    0.5%    9.0          WebCore::TimerBase::setNextFireTime(double)
47.0ms    0.1%    2.0           WebCore::TimerBase::heapPopMin()
41.0ms    0.1%    31.0            void std::__1::__push_heap_front<WebCore::TimerHeapLessThanFunction&, WebCore::TimerHeapIterator>(WebCore::TimerHeapIterator, WebCore::TimerHeapIterator, WebCore::TimerHeapLessThanFunction&, std::__1::iterator_traits<WebCore::TimerHeapIterator>::difference_type)
10.0ms    0.0%    5.0             WebCore::timerHeap()
3.0ms    0.0%    2.0              WTF::ThreadSpecific<WebCore::ThreadGlobalData>::operator WebCore::ThreadGlobalData*()
1.0ms    0.0%    1.0               pthread_getspecific
2.0ms    0.0%    2.0              DYLD-STUB$$pthread_getspecific
4.0ms    0.0%    1.0            WebCore::timerHeap()
3.0ms    0.0%    3.0             WTF::ThreadSpecific<WebCore::ThreadGlobalData>::operator WebCore::ThreadGlobalData*()
34.0ms    0.1%    0.0           WebCore::setSharedTimerFireInterval(double)
26.0ms    0.0%    20.0           void std::__1::__push_heap_back<WebCore::TimerHeapLessThanFunction&, WebCore::TimerHeapIterator>(WebCore::TimerHeapIterator, WebCore::TimerHeapIterator, WebCore::TimerHeapLessThanFunction&, std::__1::iterator_traits<WebCore::TimerHeapIterator>::difference_type)
6.0ms    0.0%    1.0            WebCore::timerHeap()
4.0ms    0.0%    3.0             WTF::ThreadSpecific<WebCore::ThreadGlobalData>::operator WebCore::ThreadGlobalData*()
1.0ms    0.0%    1.0              pthread_getspecific
1.0ms    0.0%    1.0             DYLD-STUB$$pthread_getspecific
10.0ms    0.0%    2.0           WebCore::timerHeap()
8.0ms    0.0%    6.0            WTF::ThreadSpecific<WebCore::ThreadGlobalData>::operator WebCore::ThreadGlobalData*()
2.0ms    0.0%    2.0             pthread_getspecific
3.0ms    0.0%    0.0           WebCore::stopSharedTimer()
2.0ms    0.0%    2.0           WebCore::TimerBase::alignedFireTime(double) const
2.0ms    0.0%    2.0           WTF::ThreadSpecific<WebCore::ThreadGlobalData>::operator WebCore::ThreadGlobalData*()
1.0ms    0.0%    0.0           WebCore::DOMTimer::alignedFireTime(double) const

Focusing on timerHeap():

Running Time    Self        Symbol Name
32.0ms    0.1%    11.0          WebCore::timerHeap()
18.0ms    0.0%    14.0           WTF::ThreadSpecific<WebCore::ThreadGlobalData>::operator WebCore::ThreadGlobalData*()
4.0ms    0.0%    4.0            pthread_getspecific
3.0ms    0.0%    3.0           DYLD-STUB$$pthread_getspecific

Call to pthread_getspecific is indeed pretty fast in itself. Assembly level profile shows that time is spent in indirection and branchiness related to fetching the right piece of data.

> I suggest always returning a non-const reference, the timer heap is never immutable.

You are right.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list