You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
fuzzy-finder fzf や fzy、skim などの fuzzy-search (あいまい検索) を提供する CLI ツールの登場により、コマンドラインでの操作はますます表現豊かになっています。 例えば、カレントシェルのコマンドヒストリの一覧から fuzzy-finder を使って選択したり、ghq + fuzzy-finder + cd の組み合わせで選択したリポジトリのあるディレクトリへ移動したりといったケースが挙げられます。 また、fuzzy-finder それ自体をコア機能として組み込んだツールも増えています。例えば、cd コマンドの拡張である enhancd はパスの履歴を保持し、fuzzy-finder を使って移動したいディレクトリへすぐに移動することができます。また、拙作の itunes-cli は、iTunes で管理されている曲の一覧を入力にし、fuzzy-f
この記事は Go Advent Calendar 2015 その2 の 15日目の記事です。 先日、5倍の高速化を実現した高速検索ツールThe Platinum SearcherのV2をリリースしました。 今回は、高速化にあたり工夫した点をまとめておこうと思います。 The Platinum Searcherの基本実装について 以前、GoConferenceで発表した資料にまとめてあるので、興味のあるかたはご覧ください。 基本的にはFind、Grep、PrintのGoroutineがそれぞれの結果をChannelを経由して渡すつくりになっており、それぞれのGoroutine内で並行で処理を行うために更にGoroutineを起動しています。 ボトルネックの調査 今回は完全書き直しだったのでボトルネックを潰していくという手法ではなかったのですが、再実装にあたり、気をつけるべき点を確認する上でも
http://golang.org/s/gctoc Goの新しいGCのProposalが出た.まだProposal段階であり具体的な実装はないが簡単にどのようなものであるかをまとめておく. GoのGCはGo1.5において単純なStop The World(STW)からConcurrent Mark & Sweepへと変更され大きな改善があった(詳しくは“GolangのGCを追う”に書いた).先の記事に書いたようにGo1.5におけるGCの改善は主にレイテンシ(最大停止時間)に重きが置かれいた.数値目標として10msが掲げられGo1.6においては大きなヒープサイズ(500GB)においてそれを達成していた. GCの評価項目はレイテンシのみではない.スループットやヒープの使用効率(断片化の対処)なども重要である.Go1.6までのGCではそれらについて大きく言及されていなかった(と思う).例えばスル
Go1.5とGo1.6でGoのGCのレイテンシが大きく改善された.この変更について「ちゃんと」理解するため,アルゴリズムレベルでGoのGCについて追ってみた. まずGoのGCの現状をパフォーマンス(レイテンシ)の観点からまとめる.次に具体的なアルゴリズムについて,そして最後に実際の現場でのチューニングはどうすれば良いのかについて解説する. GoのGCの今 最初にGoのGCの最近の流れ(2016年5月まで)をまとめる. Go1.4までは単純なStop The World(STW)GCが実装されていたがGo1.5からは新たなGCアルゴリズムが導入された.導入の際に設定された数値目標は大きなヒープサイズにおいてもレイテンシを10ms以下に抑えることであった.Go1.5で新たなアルゴリムが実装されGo1.6で最適化が行われた. 以下は公開されているベンチマーク.まずはGo1.5を見る. Gophe
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く