Use AtomicString type more consistently for mimeType / encoding

Use AtomicString type more consistently for mimeType / encoding

Use AtomicString type more consistently for mimeType / encoding to avoid unnecessary conversions
from String to AtomicString, as those have a cost.

AtomicString type was already used for mimeType / encoding in ResourceResponse and this CL
updates ArchiveResource to be consistent, as well as the related code.

This is one step towards making the AtomicString(const String&) constructor explicit.

R=abarth, eseidel
BUG=323739
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=163186

[eseidel, 2013-12-04 17:05:12]

StringImpl caries an "isAtomic" bit, so once the impl has been made atomic,
putting it in a string and then back into an AtomicString is free.  However if
we make a non-atomic String first and then put that into an AtomicString, that's
often "expensive".

[eseidel, 2013-12-04 17:06:46]

So long as we don't pass any of these data structures across threads this seems
fine.

[Inactive, 2013-12-04 17:50:30]

On 2013/12/04 17:05:12, eseidel wrote:
> StringImpl caries an "isAtomic" bit, so once the impl has been made atomic,
> putting it in a string and then back into an AtomicString is free.  However if
> we make a non-atomic String first and then put that into an AtomicString,
that's
> often "expensive".

Right. The thing is that I'd like to make the AtomicString(const String&)
explicit to make it more obvious when we do something potentially expensive.
Using consistently AtomicString type when passing a variable around will make
the code look better because we won't need to explicitly call AtomicString(const
String&) constructor. It also makes it obvious we have an atomic StringImpl.
When a function gets a String in argument, it is not obvious if converting it to
an AtomicString will be expensive or not.

I will double-checked that we don't pass these structures across threads but I
don't believe we do.

[Inactive, 2013-12-04 18:11:24]

On 2013/12/04 17:50:30, Chris Dumez wrote:
> On 2013/12/04 17:05:12, eseidel wrote:
> > StringImpl caries an "isAtomic" bit, so once the impl has been made atomic,
> > putting it in a string and then back into an AtomicString is free.  However
if
> > we make a non-atomic String first and then put that into an AtomicString,
> that's
> > often "expensive".
> 
> Right. The thing is that I'd like to make the AtomicString(const String&)
> explicit to make it more obvious when we do something potentially expensive.
> Using consistently AtomicString type when passing a variable around will make
> the code look better because we won't need to explicitly call
AtomicString(const
> String&) constructor. It also makes it obvious we have an atomic StringImpl.
> When a function gets a String in argument, it is not obvious if converting it
to
> an AtomicString will be expensive or not.
> 
> I will double-checked that we don't pass these structures across threads but I
> don't believe we do.

Also note that the mimeType argument to TextResourceDecoder::create() is often
created from a string literal.
Ditto for the mimeType / encoding arguments to DocumentLoader::beginWriting()
and SubstituteData constructor.

[eseidel, 2013-12-04 18:19:15]

lgtm

[commit-bot: I haz the power, 2013-12-04 18:19:31]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/99333006/1

[commit-bot: I haz the power, 2013-12-04 19:17:04]

Change committed as 163186