やっぱりJavaはここが遅い！
基本的にJavaは『遅い』と思われている。理由は二点あって、一つは過去のバージョンのJavaの実行速度が遅かった歴史的な点であり、一つは実際に依然として遅い面がある点だ。しかし、漠然と遅いと思われている事が多い。 数値演算などでは、JavaはC言語に迫る速度を出す事もある。The Computer Language Benchmarks Gameでは逆転している項目もある。しかし、Javaアプリケーションの体感速度はC++アプリケーションを上回ることは無いとされる。 これはJITコンパイラによる初期動作の遅さ、ガーベッジ・コレクション（GC）の駆動などの複合的な要因で発生する『遅さ』なのだが、単純なベンチマークだと特徴を掴みづらい。そこで変則的なベンチマークを作って、このJavaの『遅さ』を簡単に計測してみた。 1. ベンチマーク方法 コッホ曲線の描画時間を連続して測るベンチマークを作成し
throw Life - Dalvik VMのGarbage Collection概要
ちょっと時間ができたので、知り合いのブログを読みあさってました。 すると、安藤恐竜さんとこでこんな翻訳記事を見つけました。 Track memory allocations（日本語超訳） 大半のケースでは、数多くの小さくて短命なオブジェクトが原因でGCが起動される。世代別GCのような場合には、このようなオブジェクトの回収を最適化し、頻繁にGCが起動されることを防ぐことができる。AndroidのGCは、残念ながらそのような最適化を行うことができず、パフォーマンスに影響の多い一連のコードの中で、短命なオブジェクトを作ると、そのままアプリケーションの性能にとって影響が多くなってしまう。 マジっすか？！一応原文もチェック。 Track memory allocations Most of the time, garbage collection occurs because of tons
「Java SE 6完全攻略」Garbage First GC
Javaがヒープの管理にGCを使用しているのは、読者の皆さんもご存じの通りです。GCの手法にはいろいろありますが、HotSpot VMが採用しているのが世代別GCです。今回は、世代別GCの概要と問題点を解説したうえで、これを解決するために導入されたGarbage First GCについて説明します。 世代別GCの概要と問題点 世代別GCは若いインスタンスと時間を経たインスタンスを別々の領域に配置し、管理する手法です。これは寿命の短いインスタンスほど多いという性質をベースにしています。 若いインスタンスが配置される領域をヤング領域、時間を経たインスタンスを配置する領域をオールド領域とよび、それぞれの領域で異なるGCの手法を使用します。つまり、ヤングとオールドという世代の異なる領域を、それぞれ異なるGCで管理するのが世代別GCというわけです。 ヤング領域には高速ですが漏れのあるGCを用います。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
