BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Eclipse Juno のパフォーマンス問題

Eclipse Juno のパフォーマンス問題

原文(投稿日:2012/09/26)へのリンク

 

Eclipse Juno (Elipse Platform 4.2) のパフォーマンスに関する問題が Eメールスレッド で議論の嵐を起こしている。火ぶたを切ったのは,Eclipse のシルバースポンサー Cloudsmith の共同創設者である Thomas Hallgen 氏だ。Elipse b3 プロジェクトの活発なコミッタのひとりである Hallgen 氏が言うには,Eclipse をバージョン 4.2 からバージョン 3.8 に戻したところ,"切り替えた後のパフォーマンスの違いに愕然としました。3.8 プラットフォームの方がずっと,ずっと早いのです。"

Bugzilla のエントリ bug 385272 ("Juno リリースにアップデートした後の極端なレスポンス低下") は今,多くのコメントで溢れかえっている。ポストのいくつかを見る限り,最初 4.2 がローンチした時点では問題はなかったようだ。しかし開発が進むにつれて,パフォーマンスは徐々に悪化していった。一部のユーザからは,Eclipse を再起動すると,一時的に適当なパフォーマンスレベルに戻る,という報告もある。

Eclipse のエグゼクティブディレクタ Mike Milinkovich 氏は,自身の "Life at Eclipse" ブログで,これは今に始まったことではなく,原因はリソースの不足にある,と説明している。"Eclipse プラットフォームチームが重大なリソース問題を抱えているため,パフォーマンステストはオフになっています。事実は単純で,Eclipse プラットフォームチームに対して,合理的に達成可能と期待される範囲以上の負担が掛けられているのです。これは何も今に始まったことではなく,少なくとも過去3年~4年の間,多くのフォーラムで議論されてきた問題です。残念ながら,重要なコントリビューションを行う段階にまでステップアップしている組織や個人はごく限られているのです。"

InfoQ では Milinkovich 氏に対して,さらに詳しい説明を求めた。

InfoQ: この問題を Juno で修正する予定はあるのでしょうか,あるいは Kepler (Eclipse Platform 4.3) まで解決が先延ばしされるのですか。

Milinkovich: チームが Juno で重視しているのは安定性,機能,それから互換性です。これまでのリリースでは,パフォーマンスに関して大きな抗議が起きることはありませんでした。

問題の所在が確認された以上,チームとしてはできる限りの対処をしたいと思っています。近々リリースされる SR1 では,既知のメモリリークのひとつが修正されていますし,2月に予定されている SR2 でも,他の問題がいくつか解決されるはずです。 ですから Kepler 以前も,Kepler 自体でも,大きく改善されるものと思って頂いて結構です。

今回の件を改めて考えてみると,コミュニティからの反応の大きさという点では,実は 2004 年に Eclipse 3.0 を公開した時の方がずっと大きかったのです。Eclipse ほど広範に利用されているプラットフォームにおいて,大規模なオーバーホールに伴って問題が起きるというのは,さほど珍しいことではありません。

私たちは受け取った事例をすべて確認しながら,可能な限り多くのものについて対処を進めようと努力しています。このような問題を発見して修正する唯一の方法は,実際に Juno を使用した上で問題点を報告し,それを調査することなのです。Eclipse 3.9 はリリースされませんので,新機能とパフォーマンス改善はすべて 4.2 および 4.3 ストリームで実施されることになります。

InfoQ: Eclipse 財団が Eclipse 開発で果たしている役割について説明してください。

Milinkovich: 私たちの役割は開発をリードすることではなく,プロジェクトをホストして,Eclipse 開発と IP プロセスの円滑な運営を可能にすることです。Eclipse 財団のメンバは開発者やアーキテクトではありません。ユーザやプラットフォームを採用する側のニーズを満足するのは,各プロジェクトの責任です。コミュニティも,優れたフィードバック,再利用可能なテストケースを提供するという点で,大きな役割を果たします。

これまで Eclipse プラットフォームプロジェクトへのコントリビュートには,比較的複雑な手順が必要でした。近いうちにこれを変更したいと思っています。GIT への切り替えや共通的ビルドインフラストラクチャ (Maven と Tycho をベースとする) の採用,これまでよりずっとアプローチしやすくなった Eclipse 4 コードベース,といった改善が相まって,コミュニティによるコントリビュートの役割が大幅に向上するものと期待しています。

 

この記事に星をつける

おすすめ度
スタイル

BT