page0066 のバックアップ(No.5)

Javaとのサイズ対決

javacでは-g:noneを付ける。
classファイルはtek5圧縮をするし、しかも23を引いてやる。
- 23を引く根拠： 1バイトのファイルをtek5圧縮したら23バイトになったので、tek5のヘッダなどで23があるとした。
- jarにしないのは、tek5のほうが圧縮力が高いため。

none: （何もしないプログラム）
- OSECPU: 3バイト
- Java: 119バイト
hello:
- OSECPU: 15バイト（app0035）
- Java: 200バイト
- MS-DOS: 24バイト
- 「はりぼてOS」: 79バイト
- 第二世代OSASK: 16バイト
chars:
- OSECPU: 8バイト（app0036）
- Java: 229バイト
- 第二世代OSASK: 13バイト
japan: （日本の国旗を描画）
- OSECPU: 20バイト（app0087）
- Java: 220バイト
gradation:
- OSECPU: 13バイト（app0020）
- Java: 270バイト
bball:
- OSECPU: 71バイト（app0023）
- Java: 518バイト（色を白固定にしても493）
- 「はりぼてOS」: 350バイト
- 第一世代OSASK: 199バイト

バイトコードは，Javaの設計当初からネットワーク経由によるプログラムの配信を考慮し，その名のとおりコンパクトに設計されています．

noneを作って比較したのは、ヘッダというか最初のオマジナイ的なものがサイズを食っているのかどうかを確認したかったため。・・・それで比べてみると、どうもそういうわけでもないらしい。

bballでの増加傾向とかを見ると、ロジックの増加に伴い、Javaはハイペースでサイズが増えてしまう。これじゃあ大規模になればJavaが有利になるという期待もできない。
- gradation→bballで比較すると：
  - OSECPU: +58の増加
  - Java: +223の増加

というかJavaがこの程度なら、第二世代OSASK（efg01）にグラフィックス拡張をくっつけたものを作ったとしても、正直負ける気がしない・・・。OSECPUを持ち出すまでもない感じ。

一応javaを養護しておくと、javaはクラス名やメソッドのシグネチャも全部文字列で格納されているのでものすごく小規模なプログラムでは名前の情報をカットしてシステムコールを番号で呼び出せるelf等よりサイズ的に不利です -- neri 2013-08-27 (火) 01:47:06
なるほど・・・Javaはサイズ重視という割には、詰めが甘いなあ・・・。情報どうもありがとうございます！確かにダンプすると文字列がいろいろ見えます。 -- K 2013-08-27 (火) 11:57:37

コメント	お名前	NameLink