https://bugs.webkit.org/show_bug.cgi?id=35991
Would be faster to not use a thread specific to implement StringImpl::empty()
Reviewed by Darin Adler, Geoffrey Garen, Maciej Stachowiak.
JavaScriptCore:
Change JSC::UStringImpl's implementation of empty() match to match StringImpl's new implementation
(use a static defined within the empty() method), and change the interface to match too (return
a pointer not a reference).
~0% performance impact (possible minor progression from moving empty() from .h to .cpp).
(JSC::Identifier::add):
(JSC::Identifier::addSlowCase):
- runtime/PropertyNameArray.cpp:
(JSC::PropertyNameArray::add):
(JSC::initializeUString):
(JSC::UString::UString):
(JSC::UStringImpl::empty):
(JSC::UStringImpl::create):
(JSC::UStringImpl::adopt):
(JSC::UStringImpl::createUninitialized):
(JSC::UStringImpl::tryCreateUninitialized):
WebCore:
Copy JavaScriptCore in making 'static' strings threadsafe, make the empty string a static,
shared by all threads.
~2% progression on Dromaeo DOM core & JS lib tests.
- platform/ThreadGlobalData.cpp:
(WebCore::ThreadGlobalData::ThreadGlobalData):
(WebCore::ThreadGlobalData::~ThreadGlobalData):
- platform/ThreadGlobalData.h:
(WebCore::ThreadGlobalData::eventNames):
- platform/text/StringImpl.cpp:
(WebCore::StringImpl::StringImpl):
(WebCore::StringImpl::empty):
- platform/text/StringImpl.h:
(WebCore::StringImpl::deref):
(WebCore::StringImpl::hasOneRef):
|