Typhoon Storm
2012-11-30 14:46:46 UTC
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!
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!