ForceSet worked in 3.24. It is not working in 4.6.88. So I do not have a
way to override an accessor once it is set.
I am showing read and print for simplicity to demonstrate the issue using
v8 shell.cc. In my embedding app, before using accessors, creating a
context used to take ~2.9ms; after, ~0.5ms. Measured against 3.24.
On Saturday, October 31, 2015 at 3:56:50 PM UTC-7, Alex Kodat wrote
>
> Sorry, you're right -- I should have researched the history and behavior
> of CreateDataProperty and DefineOwnProperty. And, in fact, it does appear
> that they will not replace an exisiting object property. Given that, it
> seems like you have no choice other than to use ForceSet (until
> CreateDataProperty and DefineOwnProperty are fixed?).
>
> While I guess ForceSet was a little uncool in that it allowed replacing
> even non-configurable (v8::DontDelete) properties, IMO CreateDataProperty
> and DefineOwnProperty seem to go too far in the other direction.
>
> Just out of curiosity, were your examples of read and print used for
> simplicity or are these really the functions you're lazily instantiating?
> If the latter, is an accessor really that much cheaper to set up then just
> adding the function right away as an object property? I can definitely see
> using lazy instantiation for a function if it's a constructor and comes
> along with a bunch of other stuff but if it's just a simple function, I
> would think the FunctionTemplate::New()->GetFunction() isn't going to be
> noticably slower than SetAccessor. Of course, you might be doing tricky
> stuff like dynamically loading the functions or maybe compiling JavaScript
> callbacks with your function or whatever, in which case lazy instantiation
> would make perfect sense.
>
> On Saturday, October 31, 2015 at 11:03:10 AM UTC-7, Jane Chen wrote:
>>
>> Yes, the first time the property is accessed, it gets the correct native
>> function. In my accessor before I return, I have:
>>
>> global->SetAccessor(context,property,0);
>> global->CreateDataProperty(context,property,obj);
>>
>> Then the property becomes undefined the second time on.
>>
>> On Saturday, October 31, 2015 at 10:04:24 AM UTC-7, Alex Kodat wrote:
>>>
>>> CreateDataProperty or DefineOwnProperty should work. Of course, you have
>>> to make sure that the first time the function is accessed via the accessor
>>> when you do your override, you have to return the function from the
>>> accessor. But I assume you're doing that?
>>>
>>> On Friday, October 30, 2015 at 3:03:27 PM UTC-7, Jane Chen wrote:
>>>>
>>>> Is there anyway to use something like CreateDataProperty to override
>>>> the accessor so that the actual function is associated with the property,
>>>> albeit lazily created?
>>>>
>>>> I tried to use CreateDataProperty in place of ForceSet, since ForceSet
>>>> is deprecated, but that didn't do it, and my property becomes undefined.
>>>>
>>>> On Friday, October 30, 2015 at 2:12:12 AM UTC-7, Jakob Kummerow wrote:
>>>>>
>>>>> Well, the profile tells you which function was executed. It doesn't
>>>>> know or care what name you used to refer to this function -- it can't, as
>>>>> it's a sampling profiler. Pure-JS example:
>>>>>
>>>>> function f() { /* long-running stuff */ }
>>>>> var g = f;
>>>>> g(); // Shows up as "f" in the profile.
>>>>>
>>>>> In your example, the function is a C++ object, so it doesn't even have
>>>>> a name, so V8 tries to infer a name that it hopes is meaningful to a
>>>>> human
>>>>> reader. The point is that for a single function, it can only infer a
>>>>> single
>>>>> name.
>>>>>
>>>>> I think this is working as intended.
>>>>>
>>>>> On Thu, Oct 29, 2015 at 11:57 PM, Jane Chen <[email protected]> wrote:
>>>>>
>>>>>> A test case to demonstrate the issue can be found at:
>>>>>>
>>>>>> https://code.google.com/p/v8/issues/detail?id=4527
>>>>>>
>>>>>>
>>>>>> On Thursday, October 29, 2015 at 3:46:21 PM UTC-7, Jane Chen wrote:
>>>>>>>
>>>>>>> Testing profiling against v8 4.6.88.
>>>>>>>
>>>>>>> I have functions that are exposed through accessor callbacks. If a
>>>>>>> native function is set for multiple accessor properties, the last
>>>>>>> property
>>>>>>> shows up as the function name in the CpuProfileNode, regardless what
>>>>>>> name
>>>>>>> you set to the function returned by the accessor function. For example:
>>>>>>>
>>>>>>> global->SetAccessor(
>>>>>>> v8::String::NewFromUtf8(isolate, "print",
>>>>>>> v8::NewStringType::kNormal)
>>>>>>> .ToLocalChecked(),
>>>>>>> getFunction);
>>>>>>> global->SetAccessor(
>>>>>>> v8::String::NewFromUtf8(isolate, "read",
>>>>>>> v8::NewStringType::kNormal)
>>>>>>> .ToLocalChecked(),
>>>>>>> getFunction);
>>>>>>>
>>>>>>> Now "get read" is the function name in CpuProfileNode although print
>>>>>>> is called.
>>>>>>>
>>>>>>> Test script:
>>>>>>>
>>>>>>> function isPrime(num) {
>>>>>>> for (var count = 2; count < num; count++)
>>>>>>> if (num % count == 0) return false;
>>>>>>> return true;
>>>>>>> };
>>>>>>>
>>>>>>> var total = 0;
>>>>>>> for (var i = 2; i < 100000; i++) {
>>>>>>> if (isPrime(i)) {
>>>>>>> print(i);
>>>>>>> total++
>>>>>>> }
>>>>>>> };
>>>>>>> total;
>>>>>>>
>>>>>>> TotalHitCount:2233
>>>>>>>
>>>>>>> FunctionName:(root)
>>>>>>> LineNumber:0
>>>>>>> ColumnNumber:0
>>>>>>> HitCount:0
>>>>>>> FunctionName:(program)
>>>>>>> LineNumber:0
>>>>>>> ColumnNumber:0
>>>>>>> HitCount:7
>>>>>>> FunctionName:
>>>>>>> LineNumber:0
>>>>>>> ColumnNumber:0
>>>>>>> HitCount:13
>>>>>>> FunctionName:isPrime
>>>>>>> LineNumber:1
>>>>>>> ColumnNumber:17
>>>>>>> HitCount:8
>>>>>>> FunctionName:
>>>>>>> LineNumber:1
>>>>>>> ColumnNumber:1
>>>>>>> HitCount:2196
>>>>>>> FunctionName:get read
>>>>>>> LineNumber:0
>>>>>>> ColumnNumber:0
>>>>>>> HitCount:2
>>>>>>> FunctionName:(garbage collector)
>>>>>>> LineNumber:0
>>>>>>> ColumnNumber:0
>>>>>>> HitCount:7
>>>>>>>
>>>>>>>
>>>>>>> Given that an accessor callback takes a property name, it should
>>>>>>> allow one native function to handle multiple properties. Is this a
>>>>>>> bug, or
>>>>>>> am I doing something wrong?
>>>>>>>
>>>>>> --
>>>>>> --
>>>>>> v8-users mailing list
>>>>>> [email protected]
>>>>>> http://groups.google.com/group/v8-users
>>>>>> ---
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "v8-users" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to [email protected].
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
--
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
