Discussion:
This code causes Xtend editor VERY slow and sometimes hangs Eclipse
Typhoon Storm
2012-11-30 14:46:46 UTC
Permalink
Hi,

Recently I found Xtend editor to become more and more slow, to a degree of
intolerable. Today, every few keystrokes would cause workspace rebuild,
which usually spends more than 5 minutes. Absolutely no overstate.

After desperate search, I locked down the problem in a few lines of
code(I'm proud of achieving this), shown below after removing irrelevent
details. I created a new workspace, only this file in it, and record time
spent on building workspace. When testing one function, the other one is
commented out. The time is logged in the comment:

class XtendSlow {

def test() {
val (Integer, Double, Boolean) => void fun1 = null
val (byte[], Object) => double[] fun2 = null
val test = newArrayList.map[1 -> Pair::of(fun1, fun2)]
val test2 = newArrayList.map[2 -> Pair::of(fun1, fun2)]

// Integer -> Pair::of(closure1, closure2) element type, and
operations on the list,
// are from real code. Closure param types are made up though
// *build time without/with this line: 1 second vs 40 second, Great
slow down*
val test3 = Iterables::concat(test,
test2).toMap[key].entrySet.map[value].toList
}

def test2() {
val Integer fun1 = null
val double[] fun2 = null
val test = newArrayList.map[1 -> Pair::of(fun1, fun2)]
val test2 = newArrayList.map[2 -> Pair::of(fun1, fun2)]

// Simplified element type to be Integer -> Pair::of(Integer,
double[]), no more closure
*// build time without/with this line: 1s vs 4s, not so great, but
still noticable*
val test3 = Iterables::concat(test,
test2).toMap[key].entrySet.map[value].toList
}
}


The test was done in clean Eclipse DSL package installation, Xtend version
is 2.3.1.
The result shows the last line of each method causes the Xtend compiler to
greatly slow down(factor of 4x and 40x). The timing results was tested in
an empty workspace. My working workspace contains a few hundred of java
files and about 30 xtend files, so it is far more slower, as described
eariler.
And in another eclipse that has a memory meter plugin, it shows that
Eclipse is doing constant garbage collection during workspace build.
With this level of slow down, I am unable to do any programming in xtend
editor. I'll have to implement that function in java. Yet I think the code
is absolutely reasonable and should not be intentionally avoided by Xtend
user. So please check this problem and make some optimizations. I hope it
will resolve other performance issues we occasionally meet.

Best Regards!
Sven Efftinge
2012-11-30 20:48:55 UTC
Permalink
We are aware of this kind of performance issue and have already been working on a completely overhauled architecture of the type inference since April.
It's making good progress and we are also working on optimisations in other areas. The next release (probably February) will bring great relief in this regard.

Thanks for the sample code, we will use it as one of many other scenarios we already have to do the profiling and optimisation.

Cheers,
Sven
Hi,
Recently I found Xtend editor to become more and more slow, to a degree of intolerable. Today, every few keystrokes would cause workspace rebuild, which usually spends more than 5 minutes. Absolutely no overstate.
class XtendSlow {
def test() {
val (Integer, Double, Boolean) => void fun1 = null
val (byte[], Object) => double[] fun2 = null
val test = newArrayList.map[1 -> Pair::of(fun1, fun2)]
val test2 = newArrayList.map[2 -> Pair::of(fun1, fun2)]
// Integer -> Pair::of(closure1, closure2) element type, and operations on the list,
// are from real code. Closure param types are made up though
// build time without/with this line: 1 second vs 40 second, Great slow down
val test3 = Iterables::concat(test, test2).toMap[key].entrySet.map[value].toList
}
def test2() {
val Integer fun1 = null
val double[] fun2 = null
val test = newArrayList.map[1 -> Pair::of(fun1, fun2)]
val test2 = newArrayList.map[2 -> Pair::of(fun1, fun2)]
// Simplified element type to be Integer -> Pair::of(Integer, double[]), no more closure
// build time without/with this line: 1s vs 4s, not so great, but still noticable
val test3 = Iterables::concat(test, test2).toMap[key].entrySet.map[value].toList
}
}
The test was done in clean Eclipse DSL package installation, Xtend version is 2.3.1.
The result shows the last line of each method causes the Xtend compiler to greatly slow down(factor of 4x and 40x). The timing results was tested in an empty workspace. My working workspace contains a few hundred of java files and about 30 xtend files, so it is far more slower, as described eariler.
And in another eclipse that has a memory meter plugin, it shows that Eclipse is doing constant garbage collection during workspace build.
With this level of slow down, I am unable to do any programming in xtend editor. I'll have to implement that function in java. Yet I think the code is absolutely reasonable and should not be intentionally avoided by Xtend user. So please check this problem and make some optimizations. I hope it will resolve other performance issues we occasionally meet.
Best Regards!
Loading...