[webkit-dev] Initializing String and AtomicString with literals

Ojan Vafai ojan at chromium.org
Sun Aug 26 10:15:24 PDT 2012


On Fri, Aug 24, 2012 at 11:19 PM, Benjamin Poulain <benjamin at webkit.org>wrote:

> On Fri, Aug 24, 2012 at 10:18 PM, Adam Barth <abarth at webkit.org> wrote:
>
>> [[[
>> The difference between the version is if the length of the string is
>> included or not. Having the size given in the constructor makes the
>> constructor faster. Having the size also makes the code bigger, which
>> is a problem when the code is executed infrequently.
>> ]]]
>>
>> That description isn't 100% clear to me, but my reading of it is that
>> the ConstructFromLiteral version has the length of the string embedded
>> at the call site and therefore makes the code faster by increases the
>> code size.
>>
>
> Initially I thought avoiding strlen() would always be a win.
>
> In practice, I have learned the hard way that code growth can hurt us a
> lot on ARM so I wanted to provide a no-compromise option and added
> ASCIILiteral.
>
> If you use ASCIILiteral, the code does not grow a single byte. You can
> safely use it in any place where the default constructor was used and it
> always make the code faster.
>
> If you are in a place where the performance matter, or if the string is
> long and will not be used anytime soon, ConstructFromLiteral will give
> you better performance.
>

So, is the rule something like "Use ASCIILiteral unless you can show
improvement on a benchmark by using ConstructFromLiteral." Could you add
some simple explanation like that to the wiki page? As someone who doesn't
understand the implementation details, what's on the page right now doesn't
give me a clear enough rule of when to use which.


> Benjamin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120826/0810f10a/attachment.html>


More information about the webkit-dev mailing list