A performance improvement idea

[rezayi]

Hi,
I used this library in one of my projects some months ago, and performance was too crucial.
I had some performance problems:

• a part of that was because of using JNI.
• a part of that was because of mappings in both C++ and Java layers.
• Finally, a part of that was converting Java instances to v8 instances by detecting object structure using the Java Reflection for each instance.

So I decided to change my components language to C++ and work directly with V8.
I have an idea to improve the performance of your library.
You can create an ObjectTemplate for each Java class instead of processing the Java class using Reflection for creating each instance.

[caoccao]

Hi Rezaei,

Thank you for the idea.

I'm not sure how much improvement ObjectTemplate might bring, because reflection is limited to bind, some converters that are not part of the regular conversion. And, would you mind being more specific on which part of the Javet design could be replaced with ObjectTemplate.

• Primitive types - I wonder if ObjectTemplate would bring substantial benefits because the C++ layer has to call JNI to get the value, create the primitive V8 value via the raw API. I haven't profiled the performance difference between raw API and ObjectTemplate. Do you have the benchmark that could be shared?
• Compound types
  • Some built-in Java types like Map, Set, List are treated the same as primitive types are.
  • The others go through reflection API only if the specific converter is in place. That part, I'm not sure how to dynamically create ObjectTemplate to improve the performance because the reflection calls seem to be inevitable.

Thank you.

[rezayi]

Hi again,
Unfortunately, I don't have any benchmarks.
In my test case about 8 months ago, I had 10,000 Object instances. I checked the time of just binding them to v8 (not instantiating them) and it took 2500ms. But when I implemented that using C++ and I used Object Template creating these objects took only 16ms.
But I think my idea can have both performance and functionality improvements.
In the current version of Javet, we can create an Object instance in Java and bind it to v8.
When we bind a Java object to v8, in the Java part, Javet processes the object using Reflection and extracts v8Functions and v8Properties and then sends them to the C++ part using JNI. Now, the C++ part creates a v8Object and set all the properties and functions to it.
The problem is precisely here. If we have 1000 instances, we should perform the Reflection on the class 1000 times.
But, I think it's better to process classes just once, send data to C++, and then create an ObjectTemplate for each Java class. When we create an instance of this class (you can define createNewInstanceOfClass, for example, in the v8Runtime class). Just, you should send a JNI request to C++ to instantiate a new instance of the ObjectTemplate and return IdentityHash.

Now we can check this from two sides:

• performance: using Java reflection many times can impress the total performance. Using ObjectTemplate, you need just one-time processing class and reuse that data for the following times.
• functionality: in the current version of Javet, we cannot use the prototype chain concept for Custom (defined in Java) classes. Presently, any Javascript instances created for the Java instances are of type Object. But for example, in my project, I need a prototype chain.
  A sample of prototype chain in the browser:
  Element instance -> Element class -> Node class -> EventTarget class

Note: you can add “registerPackage” method to the V8Runtime class and process all package classes yourself (such as @component annotation in Spring).

[caoccao]

Thank you for detailed explanation.

Here's my understanding on what you describe. Please correct me if I'm wrong.

• It seems you were using the JavetProxyConverter or JavetBridgeConverter to inject Java object instances into V8. That's never encouraged in a performance sensitive design. Reflection has to be heavily used to provide bi-directional binding. I strongly recommend implementing a custom converter to provide bi-directional binding without reflection to immensely improve the performance. Thus, the need for ObjectTemplate is subtle.
• Regarding Using ObjectTemplate, you need just one-time processing class and reuse that data for the following times., I assume that's for uni-directional binding (Java -> V8 only). In this case, I think a custom converter is the solution which doesn't need to involve ObjectTemplate.
• Prototype is a JS concept. I'm still wondering how to elegantly expose that to JVM.
  • Prototype can be easily updated, whereas the Java object hierarchy is fixed. Mirroring the Java object hierarchy to JS prototype may cause serious inconsistency.
  • With a custom converter, all the features you describe are achievable.

In summary, I recommend a custom converter in all the cases you present and the performance overhead should be limited to the JNI calls. Your thoughts would be appreciated.

[rezayi]

I used V8ValueObject.bind to bind the Java object to v8Object.
I agree that I didn't consider the V8 to Java direction.
This direction can be implemented using the Maven plugin's auto-generated custom converter.
It's true that Prototype is a JS concept, but this concept is to handle inheritance in JS.
You can map the Java hierarchy to the JS prototype chain without problem, such as the implementation of Blink(a part of Google-chrome).
By the way, It's your choice to use ObjectTemplate or not.

Thank you.