Fast scripting...

General Discussions
#1

I’m looking into scripting for my game.

I’ve taken a look at Java’s javax.script.* package, and it just sucks in regards of speed. I’ve also taken a look at Groovy, and it’s better, runs fast with few objects (100’ish) but not fast enough with 500+.

Here’s an example of 500 images being rotated:

  1. Java’s javax.script package/Rhino: under 10 fps.

  2. Groovy: 90 fps.

  3. Just plain old Java: 480 fps.

I know scripting isn’t as fast, but I wasn’t expecting this.

What am I doing wrong?

#2

How about Pnuts?

#3

I’d be interested to see how Pnuts performs for you in relation to the others. Make sure the scripts are being compiled and not interpreted. Setting up your context like this should work:


Context context = new Context();
//context.setVerbose(true);
context.setImplementation(new CachedPnutsImpl());
context.setWriter(new PrintWriter(System.out, true));
#4

Use janino, it’s a scripting language which compiles the script to JVM bytecode so it’s just as fast as java 8)

#5

Refactored how I do things. instead of creating a new script for each object I only use one but reset the bindings between objects. Here’s the results between Groovy and Pnuts:

@500 rotating objects:

  • Groovy: 240-340 fps
  • Pnuts: 240-340 fps
  • Java: 360-500 fps

(The framerate seems to change between runs)

However, when I increase to 1000 rotating objects:

@1000 rotating objects:

  • Groovie: 60-120 fps
  • Pnuts: 120-130 fps
  • Java: 270-280 fps

Groovie seems to be more memory intensive than Pnuts, I notice it takes a bit longer to start with.

#6

Yay! Glad to see Pnuts win. :smiley:

FWIW, CachedPnutsImpl compiles and caches scripts (using WeakHashMap) for reuse when you call load(script, context). Avoiding loading the script each time is much better though. If you don’t need CachedPnutsImpl you should use context.setImplementation(new CompilerPnutsImpl()); to have scripts compiled to bytecode. If you don’t call setImplementation then it will use PnutsImpl, which is a pure interpreter.

Groovy is quite a mess of a language. I personally would rather not have such wildly different syntax. Weird that its performance varied so much.

Many JVM languages can be compiled to bytecode. They are generally still slower though, as they are usually doing more per line of code to support fancy language features.

#7

Yeah I don’t know why all the scripting languages deviate from the java syntax so much. That’s why janino’s so cool, it uses the exact java syntax. The only downside is that it doesn’t support generics or var-args yet. But janino is as quick as java (once you ‘cook’ it in the compiler).

#8

What about JavaFX?

Cas :slight_smile:

#9

The thing with Janino is… it isn’t really a scripting language. It’s a very fast on-the-fly Java compiler. That’s why you get the usual Java speed.

#10

It means it’s a better solution than using a scripting language.

#11

I dunno, I thought one of the benefits of scripting was to be free of the shackles of up front design… y’know, like ditching type declarations, the addition of top level functions, sensible overloading of the == operator, and nifty direct syntax for various types of collection…?

Cas :slight_smile: