Can you provide some performance notes related to groovy, scala, java? Or maybe some explanations about possible fan performance in some situations..
brianFri 20 Jun 2008
I don't have any benchmark data to share. But in general Fan is going to run at the same speed as Java or Scala - it is a statically typed language which compiles straight down to bytecode.
However, Fan does impose some performance trade-offs to be aware of:
The biggest performance trade-off is that Int, Float, and Decimal are boxed objects. This keeps the language pure OO without the fractured type system primitives introduce. But it does mean that numeric performance is going to be slower. This is a general problem with the dynamic languages, so I'm hoping we are going to get some JVM enhancements in the future. For example if you know that variables are only used on the local stack, you can optimize those calculations to use primitives.
Using operators like ==, !=, <, > has the extra overhead of checking whether the lhs or rhs is null; I expect HotSpot optimizes this pretty well.
using the -> dynamic invoke operator is going to drop you down to dynamic language speeds. Basically a -> call is a hash map lookup and a reflection call. When the new dynamicinvoke opcode is available the reflection part can be optimized.
The original Fan compiler was written in Java, and then ported to Fan. The performance was about the same. There was a degradation in tokenizing speed due to using boxed Ints, but I'm quite happy with the compiler's speed.
If you want to dig deep and examine the generated bytecode, the easiest thing to do is uncomment the dumpToFile line in "FanClassLoader.java", then try out some scripts.
xvik Fri 20 Jun 2008
Can you provide some performance notes related to groovy, scala, java? Or maybe some explanations about possible fan performance in some situations..
brian Fri 20 Jun 2008
I don't have any benchmark data to share. But in general Fan is going to run at the same speed as Java or Scala - it is a statically typed language which compiles straight down to bytecode.
However, Fan does impose some performance trade-offs to be aware of:
->
dynamic invoke operator is going to drop you down to dynamic language speeds. Basically a->
call is a hash map lookup and a reflection call. When the new dynamicinvoke opcode is available the reflection part can be optimized.The original Fan compiler was written in Java, and then ported to Fan. The performance was about the same. There was a degradation in tokenizing speed due to using boxed Ints, but I'm quite happy with the compiler's speed.
If you want to dig deep and examine the generated bytecode, the easiest thing to do is uncomment the
dumpToFile
line in "FanClassLoader.java", then try out some scripts.