Javaアプリを少しでも高速化するスレ

このエントリーをはてなブックマークに追加
9デフォルトの名無しさん:2005/05/07(土) 10:47:21
ウスノロ言語
10デフォルトの名無しさん:2005/05/07(土) 11:05:07
>>4
構造上、C#はJavaより遅い。
ただ、事実上Windows専用だから、グラフィックなどは最適化がしやすいんじゃないかな。
11デフォルトの名無しさん:2005/05/07(土) 17:18:54
>>4
JavaもC#も、JITコンパイラの出来次第。
12デフォルトの名無しさん:2005/05/07(土) 17:26:24
大昔に遊んだときはGCの出来が悪くて、使わなくなった変数に
明示的にnullを入れると劇的に速くなったのだが、それは今も同じ?
13デフォルトの名無しさん:2005/05/08(日) 13:24:35
J2SE5.0 でかなり改善されたと思う。以前は Swing アプリをタスクバーに納めて
数十分放置しておくと、アクティブにしようとしたときに再描画が遅れたり、
ハードディスクががりがり鳴ったりしていたけど。5.0 でこの現象がなくなった。
14デフォルトの名無しさん:2005/05/08(日) 17:13:16
今でも思いっきり起こってる
1513:2005/05/08(日) 22:38:39
え!? まじですか。なんでうちでは発生しなくなったんだろう・・・。
16デフォルトの名無しさん:2005/05/09(月) 16:09:06
正直うらやましい
17デフォルトの名無しさん:2005/05/10(火) 01:35:07
>>12
それはGCの出来ではなく、変数のスコープがおかしいから。
ttp://www-6.ibm.com/jp/developerworks/java/031114/j_j-perf08273.html
18デフォルトの名無しさん:2005/05/10(火) 07:08:16
GCなんかいらないからもっと早くならないの?
19デフォルトの名無しさん:2005/05/10(火) 17:18:30
いや、困るし
20デフォルトの名無しさん:2005/05/11(水) 10:21:46
Javaの最適化についての本かwebサイトはありませんか?
21デフォルトの名無しさん:2005/05/14(土) 17:25:09
正直、 Java って何事にもセンスが悪い。
デザインは別にいいが、エンドユーザー用のスタンダードライブラリ
とかは、糞としか言いようがない
22デフォルトの名無しさん:2005/05/14(土) 18:17:01
自分が糞なのを他人の責任にしないでください。
23デフォルトの名無しさん:2005/05/14(土) 19:49:24
起動速くならね?
24デフォルトの名無しさん:2005/05/15(日) 00:15:50
>>21
(=゚ω゚)ノ ぃょぅ、糞
25デフォルトの名無しさん:2005/05/15(日) 07:18:28
>>21は正しい。
26デフォルトの名無しさん:2005/05/16(月) 12:32:12
27デフォルトの名無しさん:2005/05/16(月) 23:48:55
>>23
1.5 だと、かなり起動速いよ。もし、そこそこの PC 使っているのに Java が
激遅だったら、ウィルス対策ソフトの設定を見直してみて。
jar や zip の読み取り時にウィルス検査するような設定だと、
信じられないほど Java が遅くなる。
28デフォルトの名無しさん:2005/05/17(火) 12:12:09
んな無茶な
29デフォルトの名無しさん:2005/05/17(火) 23:31:15
C:\Program Files\Java と C:\Eclipse 以下はウィルス検査対象外に設定するのが良い。
30デフォルトの名無しさん:2005/05/20(金) 04:41:01
解凍時に検出されるから圧縮ファイルのスキャンなんかイラネ
31デフォルトの名無しさん:2005/05/21(土) 00:11:13
>>20
いっぱいあるだろ〜。

下記の読んだんだけど、レビューにもあるように翻訳ヒドスギだった。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4873111560/ref=pd_sim_dp_2/249-5862736-5314753
32デフォルトの名無しさん:2005/05/24(火) 10:28:04
>>1の意に反してWeb系ではJavaがびっくりするほど浸透しているんだよな
33デフォルトの名無しさん:2005/05/24(火) 14:08:46
Javaの最適化って今どこら辺まで進んでいるのでしょうか?
糞?それとも結構アドバンスト?
34デフォルトの名無しさん:2005/05/24(火) 16:29:55
アドバンスドであるかどうかは
まずはTigerを使ってみるがよろし

35高木:2005/05/24(火) 18:16:47
なぜJAVAは異常に遅いのか。
オレのPC(2000年に購入したやつ)に SunJAVAいれたらぶっ壊したくなったほどだ。
36デフォルトの名無しさん:2005/05/24(火) 18:44:38
>>33
少なくともIBM JavaVMでは、↓ぐらいの最適化は行ってるようだが。
http://logic.is.tsukuba.ac.jp/~kam/ppl_ss04/ishizaki.pdf
37デフォルトの名無しさん:2005/05/26(木) 05:30:26
>>36
IBMってThinkPadにプリインストールされてるようなVMと
Websphereみたいなサーバーサイドで使われているVMが
全然別物だから、一概には言えないけどJIT技術の一般
論としてはそんなもんだろうね。

サーバーサイド(と一部組み込み向け)で採用されているJ9 VMは当時
社外だったOTIに作らせたみたいだし、36のリンク先みたいなIBM社内の研究
成果が直接使われているかは疑問だけど。
38デフォルトの名無しさん:2005/07/16(土) 14:42:42
っていうかsun java狂ってるだろ
なんで最新版入れたら突然5倍くらいアプリ読み込み遅くなったんだ。
なんか間違ってるんじゃないかと思って公式で検査してみても
おめでとうございます貴殿のpcには最新版がインスコされております。だと。
もうアホかと…
39デフォルトの名無しさん:2005/07/18(月) 18:30:25
SunのVMって、1.5から起動が急激に遅くなったよな。
ブラウザのプラグインが走り出す時なんざ、フリーズしたような状態に。
IBMの技術情報サイトでは、一部ナビゲーションに
Javaのプラグインを要求される場合があるが
IBMのVMだと軽いのにSunのは激重。 わざとか?
40デフォルトの名無しさん:2005/07/18(月) 23:34:17
そこで ガーベジゴレクション
41デフォルトの名無しさん:2005/07/18(月) 23:49:50
>>39
起動時のロゴを消すと少しは速くなる
ロゴが必要以上にCPU喰うバグが認知済みだったような
42デフォルトの名無しさん:2005/10/10(月) 17:23:15
Javaの実行速度の遅さに辟易してここ6年ほど使っていなかったのですが、最近はどうなのでしょうか?
Thunderbirdのようなソフトを見るとあまり改善されていないようにも思えるのですが・・・
結局Javaは、起動終了速度があまり関係ないサーバプログラムなどに限定されてしまうのでしょうか?
43デフォルトの名無しさん:2005/10/10(月) 17:26:11
Thunderbird は Javaアプリだっけ?
44デフォルトの名無しさん:2005/10/10(月) 18:42:29
違う
45デフォルトの名無しさん:2005/10/10(月) 19:12:04
>>42
めちゃはや
46デフォルトの名無しさん:2005/10/11(火) 01:28:18
>>42
サーバプログラムでものっそりとしか動かないね。
Cで書いたのと比べてみると5,6倍近く遅い。

そんなにサーバサイドで人数さばかなくて、小さいプログラムにならJava使ってもいいかもね。
Perlの方がいいと思うけど。
47デフォルトの名無しさん:2005/10/11(火) 02:48:59
今Cの5,6倍遅いコード書くのってむずかしそうだが
48デフォルトの名無しさん:2005/10/11(火) 13:05:21
>>12
ガベージコレクタの動作を助けたつもりでも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代入の両用により全体のパフォーマンスが極度に低下する例(決してやらないでください)
49デフォルトの名無しさん:2005/10/11(火) 13:08:00
>>46
Cでかかれたものって具体的にどんなものかkwsk
ServletみたいなのをCで再現できたのかどうかもkwsk
それともPerlやPHP程度のものに成り下がっているのかどうかもkwsk

とくにPerlはCGIとして動かすとJavaより10倍も遅くなる
50デフォルトの名無しさん:2005/10/11(火) 13:26:54
>>48
まあこのスレにJava登場時を知る人は少ないということはわかったw

要するにこういうことだな
> オブジェクトプーリングや明示的null代入は、かつてはパフォーマンスの向上に
> 役立つ斬新なアイデアでしたが、メモリの確保とガベージコレクションにかかる負荷が
> かなり軽減された現代においては、もはや必要なものでも有り難いものでもなく
> (場合によっては危害を与えることもある)なってしまいました。
51デフォルトの名無しさん:2005/10/11(火) 14:32:35
世代別GC導入前はゲームとかSystem.gcをループ内でいれるしかどうしようもなかったりしてたからなぁ

かといってこのスレが出来た日時を考えれば遅いっていつの話だとか思うわけだが

GCのおかげで高速化する場合もあるわけで
52デフォルトの名無しさん:2005/10/11(火) 14:53:16
>>49
100〜2000人ぐらいをさばくTCPサーバのプログラムで
Javaだとファイルアクセスとキューさばきが下手みたいでのろのろ動く。
PerlだとJavaよりははるかに早く動く。というかkqueue使わないCと比べても遜色ない。
PHPはやってないのでわからない。
Cはダントツ。カスタマイズしないでJavaより4,5倍早かった。

CGIでもPerlが遅いのはPerl知らないのが組んでるんじゃないかな。
JavaはPerlより遅いよ。
53デフォルトの名無しさん:2005/10/11(火) 15:20:19
あふぉな技術者だとヒープサイズ調整とかしてないことおおいからなぁ
54デフォルトの名無しさん:2005/10/11(火) 16:25:11
すまん、52を読んだだけだと52はWebアプリに関して経験不足だ
としか読み取れないんだけど、もしなにか書かれていない
制約条件があるのだったらプリーズ。
55デフォルトの名無しさん:2005/10/11(火) 16:45:04
たぶんmod_perl
56デフォルトの名無しさん:2005/10/12(水) 00:45:32
mod_perlは絶対に必要。
使わなければJavaの方がはるかに早いよ。
57デフォルトの名無しさん:2005/11/06(日) 15:38:33
速い箱使えば問題無し。
Fireでもsuperdomeでもいくらでも速い箱使えるし。

perl>javaって単にメモリが足りないだけのような。
javaはスキル低いといくらでも遅くできるよ。

貧乏人はCでも使ってごりごりやるのがいい。
58デフォルトの名無しさん
Javaで最適化できないようなCのコードって
ポインタずれてるとかメモリは介してそうだな

ようは出来ないやつはなにやっても出来ない
出来るやつはなにやっても出来る