Kotlinの隠れたコストについてのベンチマーク | POSTD
@BladeCoder が書いた Kotlinの隠れたコストの調査 という一連のブログ記事は、ある Kotlin 構文にどのように隠れたコストがあるのかを説明しました。 実際の隠れたコストは、普通、不可視オブジェクトのインスタンス化やプリミティブ値のボクシング／アンボクシングに起因します。これらのコストは、Kotlinコンパイラがどのように上記の構文をJVMのバイトコードに変換するのかを理解していない開発者には特に見えづらいのです。 しかし、何らかの数字を示さずに隠れたコストの話をするだけでは、実際にどのくらいコストのことを心配すべきなのかという疑問が湧いてきます。コードベースのいたるところで、これらのコストを考慮すべきでしょうか？あるKotlin構文は単に全面的に禁止されるべきでしょうか？あるいは、最も範囲の狭い内部ループの中でだけ考慮されるべきでしょうか？ さらに挑発的な言い方をすれば
動的配列について – JavaのLinkedListとArrayListを分析・比較する | POSTD
私はSkienaの『Algorithm Design Manual』 (訳注：『アルゴリズム設計マニュアル』 上巻 ・ 下巻 ) を読んでいました。ところでこの本は素晴らしい本で、連結リストと配列についてこんな比較をしていました(chapter 3.1.3)。 連結リストが静的配列に勝る相対的な長所には以下のものがあります。： • メモリが本当にいっぱいにならない限り、連結構造にオーバーフローが生じない。 • 連続的な(配列)リストに比べて、挿入と削除が単純である。 • 大きなレコードを扱う場合、要素自体を動かすよりもポインタを動かすほうが容易かつ高速である。 一方で、配列の相対的な長所には以下のものがあります。 • 連結構造には、ポインタのフィールドを格納するための余計な領域が必要となる。 • 連結リストでは、要素に対する効率的なランダムアクセスができない。 • 配列は、ランダムなポイン
AWS Lambdaの処理性能を言語毎に測ってみた - Taste of Tech Topics
こんにちは、@kojiisdです。 この間AWS Summit Tokyoに参加してきたのですが、皆一様に「AWS Lambda」を、 これからのサーバレスアーキテクチャを支える技術として紹介していましたね。 資料でも言葉でも多分に見聞きしており、軽いゲシュタルト崩壊を起こしている今日この頃、 皆さんはいかがお過ごしでしょうか。 さて、今回はAWS Lambdaです。 AWS Lambdaの処理はJavaやNode.js、Pythonなどの言語で記述することができますが、その性能差がどの程度あるのか？測ってみました。 構成 今回の構成は次の様なシンプルなものにしています。 [計測対象（言語）] Python Node.js Java [計測対象（カテゴリ）] 処理速度 使用メモリ [Lambdaでの処理内容] API Gatewayでリクエストを受け付け Lambda内でDynamoDBか
Mobile App Performance Redux
Since my original post, I had requests for a more comprehensive test, so I decided to include more mobile development options. In addition to Java, Swift, C#, and Ruby, I ported my logic to Objective-C and JavaScript and C++. Objective-C allowed me to get a true baseline on iOS, and JavaScript allowed me to test webviews, mobile browsers and Titanium. Facebook’s React Native will get tested when i
Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます！ 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C
Java用JSONパーザのベンチマークをした話 | さにあらず
このたび JSON パーザのベンチマークを書きましたので、どうぞご査収下さい。 taichi/json-benchmarks Java8 がインストール済みの環境で、当該リポジトリを clone して ./gradlew jmh と実行する事で追試できます。 結果について jackson-databind が最速なので殆どの皆様におかれましては安心して下さい。 特に驚きに値するような事は何も起きていません。 僕のマシンで実行した結果はこちらです。（エビデンスが無いとの指摘を受け追記しました。） Json benchmark results 結構な長文になってしまいましたので、マニアな皆様だけが続きを読んで下さい。 課題設定について まず、おおまかな課題設定について説明します。 JMH を使った本格的なベンチマークを書く Java 用 JSON パーザのショーケースを作る事で使い易いもの
Java8時代の文字列連結変態さんまとめ - きしだのHatena
いろいろな文字列連結のコードを書いた人がいたのでまとめておきますね。 主に変態さん。 とりあえず、基準として、メモリ確保したStringBuilder版 public static String stringBuilderJoinMem(){ StringBuilder s = new StringBuilder(9100).append("["); for(int i = 0; i < strarray.length; ++i){ if(i != 0){ s.append("],["); } s.append(strarray[i]); } s.append("]"); return s.toString(); } 1037ms ということで、まずはbackpaper0さん。比較的常人のコード。 https://gist.github.com/backpaper0/10273558 pu
Android開発を始めたばかりの僕が読みたかった本 - Rejasupoem
最近、スマートフォンアプリ開発をやる人増えてきてオススメの本ある？って聞かれること多くなってきたのですが、その人のバックグラウンドによるところも大きいと思うので、自分がAndroidアプリ開発を始めたときに読んでて役に立った、あるいは読んでおきたかったという目線で、良かった本をいくつか挙げようと思います。 Effective Java Java界隈では多くの人が読んでいると思いますが、AndroidからJavaに入った人だと読んだことがない人もいると思います。 Javaを書く上でのエッセンスが詰め込まれているので、まだ読んでいない方は読むことをおすすめします。 JUnit実践入門 Androidだとテストが書かれないことが多いです。しかし、書いた方がデバッグの時間が短くなる上に保守もしやすくなりますし、テストを書きやすい構造を意識するようになって、上達が早くなりますし、設計も綺麗になります
Bitmap.setPixel()をsetPixels()に変えたら３倍速くなったよ
ずいぶん前に画像をモザイク風に加工するエントリを書きましたが、あれを少しいじったらだいぶ早くなりましたよ、というご報告です。 こんなコードでモザイク処理に350～360msくらいかかってました @Override public void onPictureTaken(byte[] data, Camera camera) { BitmapFactory.Options options = new BitmapFactory.Options(); options.inSampleSize = 8; bitmap = BitmapFactory.decodeByteArray(data, 0, data.length, options); Bitmap b = bitmap.copy(Bitmap.Config.ARGB_8888, true); Log.d("CameraSample",St
Javaのパフォーマンスについての９つの誤信
JVMはプロファイリングを利用してコードの最適化を行います。対象は頻繁に利用されるコードパスのみですが，徹底的に行うことで大きな効果を上げています。JITコンパイルされたコードに関しては，現在では多くの場面において (その割合も増えつつあります) C++の実行速度を凌駕しています。 このような事実にも関わらずJavaが今でも低速なプラットフォームとして認識されているのは，おそらくは初期バージョンのJavaプラットフォームでの経験が，歴史的な負のバイアスとして働いているためでしょう。 早まった結論を出す前に，客観的な見地に立って，最新のパフォーマンス結果を評価するようにお勧めします。 2. Java コードの１行にはそれ自体で意味がある 次の短いコード行を考えてみてください： MyObject obj = new MyObject(); Java開発者ならば誰でも分かるように，このコードはオ
Javaコストメモ(Hishidama's Java cost Memo)
//throw-catch Exception t = new RuntimeException(); try { throw t; }catch(Exception e){} ←これをループ //synchronized synchronized(クラス.class) { } ←これをループ try～catchはJDK1.6で速くなっている。 逆に空ループはJDK1.4→JDK1.5で微妙に遅くなっている。とは言っても100万回で1ミリ秒未満なら、他の実行速度に比べると無視できる話だ。 synchronizedはJDK1.5で速くなったのに、JDK1.6で遅くなっている。何が変わったんだろうなぁ？ synchronizedは確かに無処理に比べれば遅いが、インスタンス生成と比べれば、文字列結合2～3個分と同じくらい？ もちろんマルチスレッドの競合の頻度にもよるだろうけど、そんなに目くじら立
文字列連結と+演算子について整理しておく - 日々常々
何度か書いているけど、整理的な意味で。今後は「このエントリ参照」にするつもりで書いてみる。 文字列連結から見るシステム内で扱う型について - 日々常々 Javaプログラマであるかを見分ける10の質問 に答えてみる - 日々常々 String の連結ネタの続き - 日々常々 前書き Stringなんてboxed primitive*1でもないただのクラスのくせに、中途半端に贔屓されて*2てムカつく*3し、その中途半端ぶり*4がなお腹立たしい……。そして +演算子 で連結して問題が起こるような状況、つまりそんな長々と文字列連結したいような場合は、きっと他の適した型がある。StringBuilderじゃなく、もっと別の何か。業務要件で文字列を組み立てる目的を考えれば、たぶんテンプレート的なものに落ち着くんじゃ無かろうか。ライブラリ的な所でなら逐次書き出し等になるような。どちらにせよ文字列の組み立
Android NDKを使用してJava言語とC言語で速度比較をする | Techfirm Android Lab
今回はAndroid NDKを使用して、JavaコードとC言語で記述されたNativeコードで速度の比較を行おうと思います。 まずはNDKをインストールします。以下のリンクからndkをダウンロードします。 http://developer.android.com/intl/ja/sdk/ndk/1.6_r1/index.html ダウンロードしてきたら以下を実行しインストールします。 $(NDKROOT)/build/host-setup.sh これでインストールが完了です。簡単ですね。 早速、Javaのコードを書いて速度比較していきましょう。 今回は簡単に１億回足し算を行い、JavaとNativeで比較してみます。 public class JniTest extends Activity { @Override public void onCreate(Bundle savedI
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Androidにおけるenum利用に関するGoogleの公式見解と考察 - Qiita
IBM Developer