JSONとMojo::JSONのencodeベンチマーク - Perl勉強メモ アルパカDiary出張版
最近mojoliciousを触る機会が多いです。 でJSON使う要件が出てきて、render_jsonってのがあるけど何使ってんのかなーと追ってみたら Mojo::JSONというのモジュールで自前実装してるっぽい。 これそのまま使えばいいんじゃね？ということで いちおうベンチマーク取ってみた。 ベンチマークスクリプト #!/usr/bin/perl use strict; use warnings; use Benchmark qw(timethese cmpthese); use JSON::PP; use JSON::XS; use Mojo::JSON; my $count = 100000; my $obj = { id => ["foo", "bar", { aa => 'bb'}], hoge => 'boge', no => 123 , bo => "true" }; my
空文字列比較は eq/ne と length のどっちが速いか - Craftworks Tech Blog - Branch
最近、空文字列のチェックの際に、面倒臭くて $_ eq '' の代わりに、空文字列だと length が偽を返すことを利用して、自分しか見ないようなソースでは以下のように書くことが多いのですが、 return unless defined and length; パフォーマンス的には、$_ ne '' と比べてどうなんだろうと思って調べてみました。 #!/usr/bin/perl use strict; use warnings; use Benchmark ':all'; my $empty = ''; my $not_empty = 'blah'; cmpthese(timethese(100000000, { emp_cmp_eq => sub { $empty eq '' }, emp_cmp_ne => sub { $empty ne '' }, emp_len => sub {
MySQLのおまとめINSERTはどれくらい速いか - bonar note
MySQLで大量のINSERT処理等をする場合、VALUES で長いクエリを作って一気に突っ込むとかなり高速になることはよく知られています。何となく10倍くらいっていう体感だったのですが、計ってみることにしました。 以下と同じスキーマのテーブル foo1, foo2 foo3 を用意します。 CREATE TABLE `foo1` ( `field1` int(10) unsigned NOT NULL DEFAULT '0', `field2` varchar(255) NOT NULL DEFAULT '', PRIMARY KEY (`field1`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 テスト環境は以下のような感じです。 Server version: 5.1.44 MySQL Community Server (GPL) 2.13 GHz
YappoLogs: トランザクションを使用したMySQLのおまとめINSERTはどれくらい速いか
トランザクションを使用したMySQLのおまとめINSERTはどれくらい速いか 元ネタはMySQL のおまとめINSERTはどれくらい速いか - bonar noteです。 トランザクションでまとめてInsertしてからcommitしたほうが速くなるので、元ネタのベンチマークをベースにして試してみました。 環境は macports で入れた mysql 5.1.44 です。 まぁnormalからbulk(100)くらいの差は出てなくても、トランザクション使ってまとめてコミットしても多少速くなっとりますね。 normal と txn の差よりも bulk(100) と bulk(100)_txn の差が小さいのは、 bulk insert で最初から効率的になってるぶん差が少なくなってるという感じでしょうか。 コードは以下の通り。 Posted by Yappo at 2010年03月09日
サーバやI/O待ちを含むベンチマークを Benchmark::cmpthese で比較してはいけない、という話 - kazuhoのメモ置き場
Benchmark.pm の cmpthese は手軽に速度の比較ができるのでとても便利。でも、そもそも何のパフォーマンスを比較しているのか？ ソースコードを読めばわかるけど、 perl プロセスのCPU使用時間 あるいは、上記＋子プロセスのCPU使用時間 を測定している。換言すると、プロセス間通信のオーバーヘッドやサーバ側での処理時間はベンチマーク結果に反映されない。つまり、サーバのベンチマーク（あるいはプロセス間通信やI/O待ちを含むベンチマーク）を比較したい場合には、cmpthese を使うべきではない。 ＃サーバと通信するクライアントモジュールのベンチマークがほしい、といった場合はOK どうしても Benchmark.pm を使いたいなら、 use Benchmark qw(:hireswallclock); my $r = timethese(...); for my $v (v
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
XML::Simple におけるパーサーの実行速度比較 - naoyaのはてなダイアリー
XML::Simple は、どんな XML でも Perl のデータ構造に自動変換してくれるかなり便利なモジュールなのですが、中でツリーを解析したりいろいろやってるせいもあって、速度的にはあまり誉められたものではありません。以前に Perl で XML の処理はどれが速いかベンチ で比較したときには、随分遅いなという印象でした。 ただ、XML::Simple はその中で利用するパーサーを色々切り替えられるようになっています。じゃあそれを切り替えたら少しは速くなるんだろうかと気になってベンチを取ってみました。 XML::Simple は $XML::Simple::PREFERRED_PARSER に任意の SAX パーサーを指定するとそれを使ってパースするようになっています。 XML::LibXML::SAX XML::SAX::Expat XML::SAX::ExpatXS XML::P
XML::Simple は遅い説における意外な落とし穴 (iandeth.)
「XML::Simpleは処理速度が遅い」説といえばNDO::Weblogさんの記事 Perl で XML の処理はどれが速いかベンチ がすぐに思い浮かびます。初見した時はずいぶん感心した覚えがあり、以来、業務で XML::Simple を使う事に多少なりとも躊躇するようになったものです。そんな中、現在仕事で XML parsing with Perl な案件を受け、CPANにUPされている様々な XML 解析系モジュールの処理速度を計測しているのですが、その際気付いた、XML::Simple の意外な落とし穴についてまとめてみました。 目次： まとめ デフォルトで呼ばれるXML::SAXパーサーの確認方法 ベンチマーク比較 関連情報 まとめ だらだら説明するのもナンなので、いきなり結論から。XML::Simple は、デフォルトの状態だと XML::SAX がインストールされている場合、
iandeth. - Benchmark モジュールの使い方、結果情報の読み方
仕事で Benchmark モジュールを使う機会があったので、使い方＆結果情報の読み取り方をまとめてみました。基本的には perldoc 読めばオールオッケーでしょ？と思っていたのですが、docs では結果情報の読み方についてはあんまり触れられていなかった為、ガッツリ補足してみました。 基本 とある２種類のコードの実行速度を比較計測するには以下のようなソースを記述します： bench.pl #!/usr/bin/perl use strict; use warnings; use Benchmark qw(timethese cmpthese); sub hogeLoop1 { my $str; for my $i (1 .. 10000){ $str .= $i } } sub hogeLoop2 { my $str; for my $i (1 .. 20000){ $str .= $i
ここギコ！: PerlのBenchmarkで出るベンチマーク値は、いったい何を表すのだろう？
2008年01月25日 PerlのBenchmarkで出るベンチマーク値は、いったい何を表すのだろう？ DoCoMoのiエリアをベースに位置情報でスタンプラリーするようなゲームを作ってるんだけど、DoCoMoのFOMA機で経緯度情報が取れるようになったのを機に、地方でダメダメなiエリアベースのスタンプエリア分けではなく、地方にも公平な独自エリアでのサービスを検討してたりする。 で、そのエリアの再構成方法として、当初iエリアのメッシュ構成を再構成して独自エリアを構成すればいいかなと思ってたのだが、蓋を開けてみると全国のメッシュ数が500万くらいあって、これを直接エリア分けするのはやってられねえ、ということで、現在GISツール等を用いてポリゴンベースでエリア分けしてたりしてる。 でもそうなると今度はポリゴンベースでエリア分けしたものをメッシュデータに変換するロジックを組むのがまた泣きそうな勢
Perl で YAML と JSON のベンチマーク比較 - Daio Today
Perl で YAML と JSON のベンチマーク比較 YAML や JSON が軽い！速い！と言われているが、どれくらい速いのか Perl モジュールでベンチしてみた。 ※個人的に興味があったのがデータの読み込み (Load) だけだったので、データの書き出し (Dump) はテストしていない。 結果的には、YAML と 比べて JSON の方が 6倍〜8倍高速。ただし、これはデータ量が少ない場合で、データ量が大きくなると 0.5倍〜0.8倍 と差が縮まってしまう。 また、YAML::Syck と JSON::Syck で比べると、データ量にかかわらずその差は数パーセント程度になってしまう。 ちなみに、Data::Dumper でダンプしたデータを eval したものとも比べてみたが、YAML を基準にすると eval は約50倍速く、YAML::Syck (と JSON::Syck)
たけまる / Perl - XML の処理はどれが速いかベンチ
_ Perl - XML の処理はどれが速いかベンチ [perl][xml] XML を多量に読み書きする予定なので，処理速度を調べてみることにしま した． パース速度については，昔の naoya さんの記事が参考になります． Perl で XML の処理はどれが速いかベンチ : NDO::Weblog RSS を対象としたベンチマークでは，正規表現が最速，次いで XML::LibXML とのことです． XML::Atom の性能を知りたかったので，同じ試験を Atom でやってみまし た．XML::Atom は内部で XML::LibXML を使っています． Benchmark: timing 10000 iterations of XML::Atom, XML::LibXML, XML::Simple, regexp... XML::Atom: 4 wallclock secs ( 3
XML::LibXMLでHTML文書を扱う - 徒書
XML::LibXML大好きな者が以下述べてみます。 しかし、XML::Liberalを除けば、XML::*なモジュールはX抜きのHTMLを食ってくれない.... と、404 Blog Not Found:perl - HTMLをXMLとして扱うで書かれていたのですが、XML::LibXML、というかその基となるCライブラリlibxml2はHTMLパーサも備えているので、直にHTMLを扱うこともできます。 ただ元がXMLパーサなだけに、少しでもHTML文書に壊れた部分があると解析エラーを起こして停止してしまいますが、幸いなことにそのエラーから回復するモードも備えています。以下サンプルを。 use strict; use warnings; use XML::LibXML; my $parser = XML::LibXML->new(); $parser->recover_silently(
DBにパスワードを保存する際に、どのハッシュを選ぶか - Yappo::タワシ
というのを速度とハッシュ後のサイズだけみてみた。 安い速いだけが選定基準にはならないって事を注意書きしとく。 # いろいろ追加した md5 : 16 sha1 : 20 sha224 : 28 sha256 : 32 sha384 : 48 sha512 : 64 hmac_sha1 : 20 hmac_sha512: 64 Rate hmac_sha512 sha512 sha384 hmac_sha1 sha224 sha256 sha1 ds_sha1 md5 hmac_sha512 36364/s -- -68% -70% -82% -89% -90% -92% -96% -97% sha512 114943/s 216% -- -4% -42% -67% -67% -74% -87% -90% sha384 119760/s 229% 4% -- -39% -65% -66% -
List::Util::firstは遅い - Islands in the byte stream (legacy)
(追記：この用途ではList::Util::firstを使うのは誤りで，List::MoreUtils::anyが意図されたコードです。効率についての結論は変わりません) List::Util::first{expr}は組み込みのgrep{expr}に似ているが，exprが最初に真になった段階でその値を返すので，grep{expr}よりも効率がいいと説明されることが多い。しかし，実際にベンチマークを取ってみると，多くの場合grep{expr}より遅い。最初の要素が真になるというfirst{expr}にとって最適な条件でさえ，要素数が40を越えたあたりでようやくgrep{expr}とほぼ同程度の速度になる。したがって，List::Util::first{expr}が効果的なケースはそれほど多くないと思われる。 また，もし単なる文字列の検索でよく，その検索をプログラム中で繰り返すならば，gre
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Template::Benchmark
wakaponさんの超☆掃き溜め帳: 配列のしゃほぅ！のベンチマーク
http://blog.moe-project.com/2010/06/27/mojotemplate%E3%81%AEescape%E3%81%AF%E9%81%85%E3%81%84%E3%80%82/
gzipとlzopの速度 - kazuhoのメモ置き場
XML::LibXML で属性を取り出すときのベンチマーク - blog.s14u.info