graalvm is very slower than nashorn

[edrobal]

Describe the issue
Comparing performance of graalvm and jvm invokeFunction is very slower with graalvm. I test the binding solution of polyglot API and it is worst.

Describe GraalVM and your environment:

• GraalVM version (latest snapshot builds can be found here), or commit id if built from source: ce-java8-20.3.0*
• JDK major version: 8.0_272
• OS: Linux 4.12.14-lp151.28.75
• Architecture: x86_64*

[chrisseaton]

Comparing performance of graalvm and jvm invokeFunction is very slower with graalvm. I test the binding solution of polyglot API and it is worst.

Can you share the code you're running? How can the issue be reproduced or demonstrated?

[munishchouhan]

@edrobal please provide the reproducer

[edrobal]

What's new ? Is my code useful ?

[munishchouhan]

@edrobal we are still waiting for a sample code or reproducer where you noticed that graalvm is slower than nashron
please share

[edrobal]

I send one two times.

graal.zip

[munishchouhan]

@edrobal I tried your code, but not able to find org.infolab.tools.Utils; class

[edrobal]

Sorry, not the good one.
graal.zip

[firatkucuk]

I can confirm that especially for small scripts and unit tests. Our pipeline duration increased from 16 mins to 29 mins after nashorn to graalvm migration. Maybe it adds the warm up duration for every single tests or dirtied spring contexts.

[munishchouhan]

@edrobal I tried the reproducer and got error:

GraalPerformanceTest.java:109: error: cannot find symbol
            Logger.getLogger(JsPerformanceTest.class.getName()).log(Level.SEVERE, null, ex);
                             ^
  symbol:   class JsPerformanceTest
  location: class GraalPerformanceTest
Note: GraalPerformanceTest.java uses or overrides a deprecated API.
Note: Recompile 

Please provide the complete reproducer with steps

[edrobal]

Replace JsPerformanceTest with GraalPerformanceTest and it's OK. I test it with Graal V21.
Regards