Say for example the Persistent<Object>* passed to the MakeWeak callback. Before 3.20 it was possible to Object::GetIndexedPropertiesExternalArrayDataLength() directly on the Persistent, but now it's necessary to Local<Object>::New() first. Or a worse case is where both a Function and Object are cached as Persistent<T> it's then necessary to do something like the following:
> > Local<Function>::New(isolate, p_fn)->Call(Local<Object>::New(isolate, > p_obj), argc, argv[]); > I'm afraid that, if you use 3.20, for the cases you've mentioned, you're stuck with that performance regression if you use the API correctly. While cutting Chrome over to this API, we had to use a lot of reinterpret_casts<Local*> to work around some of these problems. The weak callback problem we've already discovered and are in the process of fixing, but I'm not sure when the new weak callback API will arrive. For certain API functions, we can create a version that's callable from a Persistent directly, but Function::Call unfortunately isn't one of them. We have a few functions slated to have a Persistent version, like GetAlignedPointerFromInternalField, and if there are certain functions causing you pain, we can look at adding them if you send me a list. If there's any path by which a function might allocate heap memory, however, we cannot add it. This actually takes most functions out of contention. -- -- 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/groups/opt_out.
