Javaアプリを少しでも高速化するスレ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2005/05/07(土) 10:03:17Javaアプリ特有のもっさり感を少しでも低減しようとする方法をこのスレで考えていきましょう。
0002デフォルトの名無しさん
2005/05/07(土) 10:04:210003デフォルトの名無しさん
2005/05/07(土) 10:13:40やっぱウスノロな奴に愛されてるんだろうなｗ
0004デフォルトの名無しさん
2005/05/07(土) 10:15:0500051
2005/05/07(土) 10:18:210006デフォルトの名無しさん
2005/05/07(土) 10:27:01いや、別におかしいとは思いませんが。
ただ、ふつーは，
「低減しようとする方法」→「低減する方法」でしょうか？
0007デフォルトの名無しさん
2005/05/07(土) 10:28:44常に最新版を利用する。
0008デフォルトの名無しさん
2005/05/07(土) 10:32:080009デフォルトの名無しさん
2005/05/07(土) 10:47:210010デフォルトの名無しさん
2005/05/07(土) 11:05:07構造上、C#はJavaより遅い。
ただ、事実上Windows専用だから、グラフィックなどは最適化がしやすいんじゃないかな。
0011デフォルトの名無しさん
2005/05/07(土) 17:18:54JavaもC#も、JITコンパイラの出来次第。
0012デフォルトの名無しさん
2005/05/07(土) 17:26:24明示的にnullを入れると劇的に速くなったのだが、それは今も同じ？
0013デフォルトの名無しさん
2005/05/08(日) 13:24:35数十分放置しておくと、アクティブにしようとしたときに再描画が遅れたり、
ハードディスクががりがり鳴ったりしていたけど。5.0 でこの現象がなくなった。
0014デフォルトの名無しさん
2005/05/08(日) 17:13:16001513
2005/05/08(日) 22:38:390016デフォルトの名無しさん
2005/05/09(月) 16:09:060017デフォルトの名無しさん
2005/05/10(火) 01:35:07それはGCの出来ではなく、変数のスコープがおかしいから。
ttp://www-6.ibm.com/jp/developerworks/java/031114/j_j-perf08273.html
0018デフォルトの名無しさん
2005/05/10(火) 07:08:160019デフォルトの名無しさん
2005/05/10(火) 17:18:300020デフォルトの名無しさん
2005/05/11(水) 10:21:460021デフォルトの名無しさん
2005/05/14(土) 17:25:09デザインは別にいいが、エンドユーザー用のスタンダードライブラリ
とかは、糞としか言いようがない
0022デフォルトの名無しさん
2005/05/14(土) 18:17:010023デフォルトの名無しさん
2005/05/14(土) 19:49:240024デフォルトの名無しさん
2005/05/15(日) 00:15:50(=ﾟωﾟ)ﾉ ぃょぅ、糞
0025デフォルトの名無しさん
2005/05/15(日) 07:18:280026デフォルトの名無しさん
2005/05/16(月) 12:32:120027デフォルトの名無しさん
2005/05/16(月) 23:48:551.5 だと、かなり起動速いよ。もし、そこそこの PC 使っているのに Java が
激遅だったら、ウィルス対策ソフトの設定を見直してみて。
jar や zip の読み取り時にウィルス検査するような設定だと、
信じられないほど Java が遅くなる。
0028デフォルトの名無しさん
2005/05/17(火) 12:12:090029デフォルトの名無しさん
2005/05/17(火) 23:31:150030デフォルトの名無しさん
2005/05/20(金) 04:41:010031デフォルトの名無しさん
2005/05/21(土) 00:11:13いっぱいあるだろ〜。
下記の読んだんだけど、レビューにもあるように翻訳ヒドスギだった。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4873111560/ref=pd_sim_dp_2/249-5862736-5314753
0032デフォルトの名無しさん
2005/05/24(火) 10:28:040033デフォルトの名無しさん
2005/05/24(火) 14:08:46糞？それとも結構アドバンスト？
0034デフォルトの名無しさん
2005/05/24(火) 16:29:55まずはTigerを使ってみるがよろし
0035高木
2005/05/24(火) 18:16:47オレのPC(2000年に購入したやつ)に SunJAVAいれたらぶっ壊したくなったほどだ。
0036デフォルトの名無しさん
2005/05/24(火) 18:44:38少なくともIBM JavaVMでは、↓ぐらいの最適化は行ってるようだが。
http://logic.is.tsukuba.ac.jp/~kam/ppl_ss04/ishizaki.pdf
0037デフォルトの名無しさん
2005/05/26(木) 05:30:26IBMってThinkPadにプリインストールされてるようなVMと
Websphereみたいなサーバーサイドで使われているVMが
全然別物だから、一概には言えないけどJIT技術の一般
論としてはそんなもんだろうね。
サーバーサイド(と一部組み込み向け)で採用されているJ9 VMは当時
社外だったOTIに作らせたみたいだし、36のリンク先みたいなIBM社内の研究
成果が直接使われているかは疑問だけど。
0038デフォルトの名無しさん
2005/07/16(土) 14:42:42なんで最新版入れたら突然５倍くらいアプリ読み込み遅くなったんだ。
なんか間違ってるんじゃないかと思って公式で検査してみても
おめでとうございます貴殿のpcには最新版がインスコされております。だと。
もうアホかと…
0039デフォルトの名無しさん
2005/07/18(月) 18:30:25ブラウザのプラグインが走り出す時なんざ、フリーズしたような状態に。
IBMの技術情報サイトでは、一部ナビゲーションに
Javaのプラグインを要求される場合があるが
IBMのVMだと軽いのにSunのは激重。 わざとか?
0040デフォルトの名無しさん
2005/07/18(月) 23:34:170041デフォルトの名無しさん
2005/07/18(月) 23:49:50起動時のロゴを消すと少しは速くなる
ロゴが必要以上にCPU喰うバグが認知済みだったような
0042デフォルトの名無しさん
2005/10/10(月) 17:23:15Thunderbirdのようなソフトを見るとあまり改善されていないようにも思えるのですが・・・
結局Javaは、起動終了速度があまり関係ないサーバプログラムなどに限定されてしまうのでしょうか？
0043デフォルトの名無しさん
2005/10/10(月) 17:26:110044デフォルトの名無しさん
2005/10/10(月) 18:42:290045デフォルトの名無しさん
2005/10/10(月) 19:12:04めちゃはや
0046デフォルトの名無しさん
2005/10/11(火) 01:28:18サーバプログラムでものっそりとしか動かないね。
Cで書いたのと比べてみると５，６倍近く遅い。
そんなにサーバサイドで人数さばかなくて、小さいプログラムにならJava使ってもいいかもね。
Perlの方がいいと思うけど。
0047デフォルトの名無しさん
2005/10/11(火) 02:48:590048デフォルトの名無しさん
2005/10/11(火) 13:05:21ガベージコレクタの動作を助けたつもりでもJavaのプログラムでは、メモリの確保と解放が一度に実行
されるとパフォーマンスが極度に低下します。
そのため、オブジェクトプーリングや null代入といった多くの巧妙な技術が考案されました。しかしながら、
多くの場合において、こういった手法はパフォーマンスを向上させるどころか、むしろ低下させる結果を招い
てしまいました。
http://www-6.ibm.com/jp/developerworks/java/040312/j_j-jtp01274.html
明示的null代入
明示的null代入は、単に使い終わった参照オブジェクトにnullを代入するというものです。この手法は
オブジェクトをよく早くガベージコレクションの対象にするという考え方から生まれました。少なくとも
理論上はそれが正しいとされています。
明示的null代入が、有効であるというだけでなく事実上必要とされる場合 もあります。それはオブジェク
トへの参照が、実際に使われる範囲よりも広いスコープで要求されている場合や、プログラムの仕様上
それが妥当だと考えられている場合です。ローカル変数を使わず、一時的なバッファにオブジェクトの参
照を確保しておくためのスタティックもしくはインスタンスの領域を使う場合（参考文献からリンクしている
「Eye on performance: Referencing objects」での使用例をご参照ください）や、プログラムの必要性から
ではなく、実行時に常に参照される可能性があるという意味で、オブジェクトの参照を配列に保持しておく
場合などが、これに当てはまります。配列による単純な有限スタックの実装を示したリスト3のクラスをご
覧ください。仮に明示的 null代入を行なわずにpop()を呼んだ場合、このクラスはメモリリーク（正確には
「意図しないオブジェクト保持」と呼びます。また「オブジェクト浮遊」と呼ばれることもあります）を引き起
こす可能性があります。なぜなら、stack[top+1]に保持された参照は、既にプログラム上は必要とされな
くなっているのに、ガベージコレクタがまだこれを必要なものとみなしているからです。
リスト4. ファイナライザと明示的null代入の両用により全体のパフォーマンスが極度に低下する例（決してやらないでください）
0049デフォルトの名無しさん
2005/10/11(火) 13:08:00Cでかかれたものって具体的にどんなものかkwsk
ServletみたいなのをCで再現できたのかどうかもkwsk
それともPerlやPHP程度のものに成り下がっているのかどうかもkwsk
とくにPerlはCGIとして動かすとJavaより10倍も遅くなる
0050デフォルトの名無しさん
2005/10/11(火) 13:26:54まあこのスレにJava登場時を知る人は少ないということはわかったｗ
要するにこういうことだな
> オブジェクトプーリングや明示的null代入は、かつてはパフォーマンスの向上に
> 役立つ斬新なアイデアでしたが、メモリの確保とガベージコレクションにかかる負荷が
> かなり軽減された現代においては、もはや必要なものでも有り難いものでもなく
> （場合によっては危害を与えることもある）なってしまいました。
0051デフォルトの名無しさん
2005/10/11(火) 14:32:35かといってこのスレが出来た日時を考えれば遅いっていつの話だとか思うわけだが
GCのおかげで高速化する場合もあるわけで
0052デフォルトの名無しさん
2005/10/11(火) 14:53:16100〜2000人ぐらいをさばくTCPサーバのプログラムで
Javaだとファイルアクセスとキューさばきが下手みたいでのろのろ動く。
PerlだとJavaよりははるかに早く動く。というかkqueue使わないCと比べても遜色ない。
PHPはやってないのでわからない。
Cはダントツ。カスタマイズしないでJavaより4,5倍早かった。
CGIでもPerlが遅いのはPerl知らないのが組んでるんじゃないかな。
JavaはPerlより遅いよ。
0053デフォルトの名無しさん
2005/10/11(火) 15:20:190054デフォルトの名無しさん
2005/10/11(火) 16:25:11としか読み取れないんだけど、もしなにか書かれていない
制約条件があるのだったらプリーズ。
0055デフォルトの名無しさん
2005/10/11(火) 16:45:040056デフォルトの名無しさん
2005/10/12(水) 00:45:32使わなければJavaの方がはるかに早いよ。
0057デフォルトの名無しさん
2005/11/06(日) 15:38:33Fireでもsuperdomeでもいくらでも速い箱使えるし。
perl>javaって単にメモリが足りないだけのような。
javaはスキル低いといくらでも遅くできるよ。
貧乏人はCでも使ってごりごりやるのがいい。
0058デフォルトの名無しさん
2005/11/06(日) 15:44:10ポインタずれてるとかメモリは介してそうだな
ようは出来ないやつはなにやっても出来ない
出来るやつはなにやっても出来る
■ このスレッドは過去ログ倉庫に格納されています