Have the Blob constructor use the V8TRYCATCH_FOR_V8STRINGRESOURCE_VOID() macro

Have the Blob constructor use the V8TRYCATCH_FOR_V8STRINGRESOURCE_VOID() macro

Have the Blob constructor use the V8TRYCATCH_FOR_V8STRINGRESOURCE_VOID() macro
instead of toWebCoreString() + V8TRYCATCH_VOID(). There is no behavior change.

TEST=fast/files/blob-constructor.html
R=haraken
BUG=

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=157662

[haraken, 2013-09-11 14:18:19]

LGTM.

Just a note: Allocation of a trycatch block is slow, so we need to be careful
when introducing the trycatch block in performance-sensitive places. I don't
think that your CLs so far have performance issues.

[do-not-use, 2013-09-11 14:25:39]

On 2013/09/11 14:18:19, haraken wrote:
> LGTM.
> 
> Just a note: Allocation of a trycatch block is slow, so we need to be careful
> when introducing the trycatch block in performance-sensitive places. I don't
> think that your CLs so far have performance issues.

I don't understand:
toWebCoreString() does:
    inline String toWebCoreString(v8::Handle<v8::Value> value)
    {
        V8StringResource<> stringResource(value);
        if (!stringResource.prepare())
            return String();
        return stringResource;
    }

#define V8TRYCATCH_FOR_V8STRINGRESOURCE_RETURN() does:
    type var(value);
    if (!var.prepare())
        return retVal;

Considering the arguments we use it becomes:
    V8StringResource<> var(value);
    if (!stringResource.prepare())
        return retVal;

As far as I can tell, the only difference is that we use to call a function and
now we use a macro instead. However, the code executed is the same. As a result,
you can return early if StringResource.prepare() failed. With toWebCoreString(),
it returns a String().

In both cases, an exception is thrown on JS side. I must be missing something
because I don't understand how such change can affect performance.

[haraken, 2013-09-11 15:37:19]

> > Just a note: Allocation of a trycatch block is slow, so we need to be
careful
> > when introducing the trycatch block in performance-sensitive places. I don't
> > think that your CLs so far have performance issues.
> 
> As far as I can tell, the only difference is that we use to call a function
and
> now we use a macro instead. However, the code executed is the same. As a
result,
> you can return early if StringResource.prepare() failed. With
toWebCoreString(),
> it returns a String().
> 
> In both cases, an exception is thrown on JS side. I must be missing something
> because I don't understand how such change can affect performance.

I'm sorry, you're right. There would be no perf diff between toWebCoreString()
and V8TRYCATCH.

The perf issue I've seen before is when we replaced 'Type* val = foo()' with
'V8TRYCATCH_VOID(Type*, val, foo())'. (e.g.,
https://codereview.chromium.org/18677002/diff/1/Source/bindings/scripts/CodeG...)
In this case, the perf regressed because we introduced a new TryCatch block.

[commit-bot: I haz the power, 2013-09-12 05:24:41]

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

[commit-bot: I haz the power, 2013-09-12 06:26:39]

Change committed as 157662