スライスでのアクセスのほうがパフォーマンスが出ると思っているが、 実際どの程度の差なのか少し気になったので測ってみた。 datafile.yaml データ構造を考えるのがめんどくさかったので、ここから拾ってきました。 るびま teams: - name: Akudaman members: - name: Mujo age: 24 leader: yes - name: Tobokkee age: 25 - name: Donjuro age: 30 - name: Doronboo members: - name: Doronjo age: 24 leader: yes - name: Boyakkie age: 25 - name: Tonzuraa age: 30 array_slice.pl use Benchmark qw( cmpthese ); use Config::YAM
In each of the charts below, a bigger bar and higher number for performance is better. In the performance drop-off charts a higher (less negative) percentage is better, that is -75% is better than -95%. Proportionally speaking, a narrow difference between the biggest and smallest colours of the performance drop-off chart is better than a wide difference, although pay attention to the percentage va
京都観光で散財しすぎて貯金がないmalaです。こんにちは。キャッシュの話を書きます。 色んなキャッシュがあります データベースから引く前にmemcachedから取得したり テンプレートエンジンのレンダリング結果をキャッシュしたり 各種ウェブサービスのリクエスト結果をキャッシュしたり その他諸々CPUを食ったり時間のかかる処理をキャッシュしたり 簡単に思いつくのはこの程度ですが、スケーラブルなウェブサイトを構築するには常識的に考えてそんなのキャッシュしねーだろうというようなものをキャッシュする必要があります。 DateTimeをキャッシュしよう 同じ時刻に対するDateTimeオブジェクトをキャッシュします。 package MyDateTime; use strict; use base qw(DateTime); my %CACHE; sub now { my $class = shif
Slides of my talk on Devel::NYTProf and optimizing perl code at OSCON in July 2010. It covers the new features in NYTProf v4 and outlines a multi-phase approach to optimizing your perl code. Best viewed fullscreen. A screencast of this talk, that includes a demo, can be viewed at http://blip.tv/file/3913278 An updated version of the slides can be viewed at http://www.slideshare.net/Tim.Bunce/devel
大規模なコードベースでリファクタリングを省エネ化するためにcodemodを最近調べていて、軽く試行錯誤したのでそのメモ。 やりたいこと 例えば以下のようなTable Driven TestなコードをBEFOREからAFTERに書き換えたい。コード量が多いため人間がやるのは現実的ではなく、codemodで機械的に書き換えたい。 BEFORE package main import ( "slices" "testing" ) func TestContains(t *testing.T) { type args struct { ss []string s string } tests := []struct { name string args args want bool }{ { name: "empty: false", args: args{[]string{}, ""}, wan
最適化の心得 or HTTP::MobileAttribute最適化祭りに参加してみた HTTP::MobileAttributeの最適化祭りに突発的に参加してみた。 正直言うと未だにHTTP::MobileAttributeの中身であるClass::Componentを分かってない。なのでできることも限られてるわけだが。 今回のミニ祭りを見ていてよくわかるのは結局のところスピードに最も影響があるのは端的なコードの書き方ではなく構造(ストラクチャ)を見直す事であるというだ。id:tokuhiromのところでパフォーマンスチューニングの結果を追ってる人はわかると思うけど、結局俺が参加したのはもう本当にコードの書き方をチューニングするというレベルのところで、例えばループをアンロールしてif/elseで実装してみるとかね。でもそこはどんなにがんばっても数%のパフォーマンスゲインにしかならない。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く