ふたつのIterator - プログラマーの脳みそ
コードを書いているとたまにふたつのIteratorをいっしょに回すコードを書くはめになる。 /** ふたつのItaratorを並べて回すサンプル */ static boolean compare1(List<String> list1, List<Integer> list2) { if (list1.size() != list2.size()) { throw new IllegalArgumentException("個数の不一致"); } Iterator<String> ite1 = list1.iterator(); Iterator<Integer> ite2 = list2.iterator(); // 敢えてショートサーキットしない&演算を用いる while (ite1.hasNext() & ite2.hasNext()) { String v1 = ite1.nex
軽い気持ちでLinkedListを使ったら休出する羽目になった話 - Qiita
ざっくり言うと リスト構造のデータに対してランダムアクセスはしちゃだめだぞ。お兄さんとの約束だ！ 発端 数年前に他部署の支援で作ったJavaのシステムに、ちょっとデカめのデータを突っ込んだらありえないほど遅いので助けてくれ、と連絡が入った。 まぁクエリとかインデックスをちょっと見れば直るっしょ・・・と鼻をほじりながら支援に向かった。 処理内容 遅い部分の処理は以下のようなものであった。 処理対象のデータをListで受け取る。 それをforループで1件ずつ前処理する。 処理結果をオブジェクトに格納し、ORマッパーでDBにINSERTする。 これだけ？ そう、これだけだ。並列処理なんて高級なことはもちろんやってない。 インフラ調査 処理中のサーバのようすを調査する。今回のインフラは典型的な3層3サーバ構成。 WEBサーバはなにもかもが余裕。 APサーバではCPUを1つ使い切っている。 14コア
Java8 で java.lang.Object#hashCode() の生成アルゴリズムが変更されていました。 - 地平線に行く
java.lang.Object#hashCode()の性質という記事で書いたのですが、Java の Object#hashCode() の値はただの乱数となっています。 この乱数のアルゴリズムが、Java SE 8 で「線形合同法」から「XORシフト方式」に変更になっていました。 といっても、変更されたのはたった1文字。 VMオプションのデフォルト設定が -XX:hashCode=0 から -XX:hashCode=5 に変わっただけでした。 hotspot-rt Udiff hotspot/src/share/vm/runtime/globals.hpp どういうこと？ もともと、Java の以前の実装*1 *2から、Object#hashCode() のアルゴリズムはVMオプション -XX:hashCode=? で選べるようになっていました。 ですが、デフォルトは長いこと 0(=線形
ハッシュは本当に遅いのか？いや、遅くない（反語） - プログラマはサイコロを振らない
この記事を簡潔にまとめた記事「ハッシュは二分木（ツリー）より速い」を掲載しました。（2008-08-04） ハッシュと二分木（ツリー）*1では普通はハッシュの方が速いとされる（ハッシュは挿入、参照、削除の時間計算量がO(1)、二分木はO(log N)）。しかし、ハッシュは動作が複雑なため、実際はあまり二分木と速度が変わらないとも言われる。 それをC++で検証した記事を見つけた。結論は、二分木よりハッシュの方が遅いというものだ。 ハッシュは本当に速いのか? - S34 http://www.s34.co.jp/cpptechdoc/article/hash/ ハッシュは本当に遅いのか - 山に生きる http://d.hatena.ne.jp/pmoky/20050502/1114966341 では、JavaのHashSetとTreeSet（またはHashMapやTreeMap）でも同じこと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Javaを使うなら理解しておきたいアルゴリズム - 抽出・ソート・結合・集計 (リスト＆マップ編) - 何かしらの言語による記述を解析する日記
