Worst case, if you needed to keep String::adopt(Vector), it seems like you could use a bit in StringImpl::m_hashAndFlags to record the fact that the buffer requires special "free" handling.
-Darin On Wed, Dec 7, 2011 at 10:24 AM, Adam Barth <[email protected]> wrote: > We originally used String::adopt(Vector) in the parser because we > thought it would be faster, but studying profiles and experimenting > with benchmarks revealed that (at least for those use cases) it was > actually slower than just memcpying the data into the String. I > haven't looked at the other uses of String::adopt(Vector) in the > codebase, but they might also run faster using memcpy. > > I think it's probably fine to remove String::adopt(Vector). > > Adam > > > On Wed, Dec 7, 2011 at 10:10 AM, Darin Adler <[email protected]> wrote: > > For vectors with no inline capacity, we can store the capacity inside > the Vector’s buffer. That way, the Vector itself will be one size_t smaller > when empty. In fact, with a bit of performance risk, we can do the same > thing with the vector’s size, making an empty Vector just a single pointer. > But doing this also means that the allocated buffer won’t have the vector > elements at the start of the memory block. The only thing I could find that > this would interfere with would be the String::adopt(Vector) function. My > question is whether with the latest wonderful StringBuilder technology we > could eliminate String::adopt(Vector). Can we get rid of that entirely from > WebKit? > > > > -- Darin > > _______________________________________________ > > webkit-dev mailing list > > [email protected] > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
