Bolts-Androidで連続したHTTPリクエストをウォーターフォールにする - Islands in the byte stream (legacy)
Facebook (Parse) が開発している Bolts-Android は asyn.js のように、ネストしたコールバック呼び出しをウォーターフォールで記述できるライブラリである。 コールバックのネストをウォーターフォールで記述できるというのもありがたいが、処理をTaskに分割することで、非同期リクエストを組み合わせて使うことも簡単になっている。 Boltsを使わない、ネストした一連のHTTPリクエストは以下のようになる。ここではandroid-async-httpを使った。 https://github.com/gfx/Android-BoltsExample/blob/master/app/src/main/java/com/github/gfx/boltsexample/app/MainActivity.java private void nestedRequests() {
Perlのメモリリークを見つける方法 - Islands in the byte stream (legacy)
Perlではメモリリーク検出ツールがいくつか開発されているので、top(1)の結果を眺めるよりそういうツールを使うほうが楽である。 さて、メモリリークが発生しているとき、その可能性としてはだいたい以下の4つが挙げられる。 Perlレベルでの循環参照 グローバル変数に値をどんどん足しているとき*1 XSレベルでリファレンスカウントの管理ミス XSレベルでmalloc()したメモリの管理ミス この1-3についてはすべてPerlインタプリタ内の出来事であり、Test::LeakTraceを使って検出できる。4を検出するのは難しいが、Test::Valgrindが役に立つ。 Test::LeakTraceのSYNOPSISは歴史的経緯によりごちゃごちゃしているが、テストで使うべき関数はno_leaks_ok()とleaks_cmp_ok()だけである。 たとえば、以下のようにして使う*2。 #!p
Xslate with Direct Threaded Code - Islands in the byte stream (legacy)
Ruby 1.9が採用しているVMの最適化手法に、Direct Threaded Codeというものがあるらしい。 YARV Maniacs #3 ターゲットコードが大きくなる代わりにVMの実行ループがかなり速くなるようだ。これを、Xslateに採用しない手はない、ということで簡単に実装してみた。 ブランチ：direct_threaded_code masterにマージした。0.1036からはコンパイラがGCCのときに選択される。 実行ループ*1:http://gist.github.com/446673 従来のVMとパフォーマンスを比較すると、10%ほど高速化している。 従来のVM： $ perl benchmark/interpolate.pl Perl/5.10.1 i686-linux Text::Xslate/0.1035 Text::MicroTemplate/0.11 Rat
来年から株式会社ディー・エヌ・エーで働きます - Islands in the byte stream (legacy)
文系・不況・経歴に傷ありと三重苦を負っての就職活動でどうなることかと心配でしたが、無事就職活動を終えることができました。DeNAに就職します。Perlができると就職できるというのは本当でしたね。 今回の就職活動においては、竹迫さんと牧さんには具体的な相談に乗っていただくなどお世話になりました。改めて御礼申し上げます。またその他関わった方々にも感謝致します。 私が就職できたのは、Shibuya.pmがあればこそ。Shibuya.pmというコミュニティへの参加が、ソフトウェアエンジニアとして生きることに確信を与えてくれたのです。竹迫さんをはじめとして、tokuhiromや牧さん、宮川さん、Yappo、typesterさんなどから得たものは、それ以前の独学で得たものより遥かに多様でした。特にtokuhiromとの出会ったことで、人とプログラミングについて語る喜びを知ったのは大きな財産です。牧さん
Xslate, as of 0.1009 - Islands in the byte stream (legacy)
id:tokuhirom の助言を受けて、APIの見直しなどをした*1。 キャッシュディレクトリのデフォルトが、テンプレートファイルと同じディレクトリからFile::Spec->tmpdirへ。これはcache_dirオプションで変更もできる 一引数の render(\%vars) は混乱を招くため廃止。文字列をのレンダリングはrender_string($str, \%vars)を使うようにした fileオプションとstringオプションも混乱を招くため廃止 TT風構文でINCLUDE、UNLESS、関数呼び出し、メソッド呼び出しをサポートした importオプションでモジュールの関数を使えるようにした。エクスポート可能な関数であれば自由に使えるので、単純なラッパープラグインのための特別な名前空間は必要ない。 また、テンプレートカスケーディングを拡張し、cascade with ...が
bytes.pm will be deprecated in Perl 5.12 - Islands in the byte stream (legacy)
[追記]その後deprecated（廃止予定）ではなくstrongly discouraged（強く非奨励）に状態が改められたが、使用すべきでないという点は変わらない。[/追記] bleadperlのコミットログを眺めていたところ，以下のような記述があった。 deprecate bytes.pm この件でTwitterで議論が起きたので，Togetterでまとめてみた。 #perl bytes.pmがdeprecatedになった件*1 要点をまとめると以下のようになる。 Perlの文字列モデルを正しく理解していれば，bytes.pmを使う必要はない 入力されたデータををdecode，出力するデータをencodeする，というスタイルを採用すれば，bytes::lengthなどは必要ない たとえば，PSGIの仕様では，encodeした文字列を渡すことになっている decode/encodeが面
XS基礎文法最速マスター - Islands in the byte stream (legacy)
元ネタ：Perl基礎文法最速マスター(id:perlcodesample) XSを始めるための手順といくつかの要素の解説です。C言語をある程度知っている人でも，これを読んだだけでXSの基礎をマスターしてXSを書くことができるようにはなっていません。リファレンスでもありません。 XSとは，狭義ではPerlでエクステンションを書くためのマクロ言語の名前ですが，広義ではエクステンションを書くための技術の総称です。ここでは，広義のXSを俯瞰します。 XSはいろいろと特殊なのでテンプレは無視で行きます。 目次： h2xsで空のディストリビューションを作る XSファイルの構成 スレッドコンテキスト SVファミリ GCとスコープ さらなる学習のために h2xsで空のディストリビューションを作る 以下のコマンドで空のXSディストリビューションを作ることができます。 h2xs -A -b 5.8.1 -n
Now Text::MicroTemplate is even faster than HTML::Template::Pro - Islands in the byte stream (legacy)
前提：Text::MicroTemplateの速度を簡単にベンチマーク Text::MicroTemplateを最適化したので，ベンチマークをとってみた。 スクリプトはほぼ同じだが，loop countは-1*1にした。 http://github.com/kazuho/p5-text-microtemplate/blob/master/author/benchmark_templates.pl キャッシュを有効にした結果*2： $ perl benchmark_templates.pl Perl/5.10.1 (i686-linux) HTML::Template/2.9 HTML::Template::Compiled/0.94 HTML::Template::Pro/0.92 Template/2.22 Text::MicroTemplate/0.09 Benchmark: runn
How fast Mouse-XS in applications - Islands in the byte stream (legacy)
v0.40_06から，Mouseが生成するコンストラクタとデストラクタもXSになった。Mouseが生成するアクセサはすでにXS化しているので，かなりのパフォーマンスが期待できるようになったはずだ。 しかし，いくらコンストラクタやアクセサといった部品が速くても，アプリケーションが高速にならなければ意味がない。 そこで，Any::Mooseを使ったモジュールであるHTTP::Engineで，PP版とXS版の速度差を比較してみた。 結果： Perl/5.10.1 (i686-linux) load HTTP::Engine, new(), and run() Rate PP XS PP 789/s -- -55% XS 1748/s 122% -- load HTTP::Engine, new(), and run() * 100 Rate PP XS PP 16.7/s -- -20% XS
[Perl]UTF8-flagged strings affects regexps with the "i" modifier - Islands in the byte stream (legacy)
HTML::FillInForm::Liteの使いどころという記事で，HTML::FillInForm::Liteが遅いということが取り上げられていた。 試しに記事内のベンチマークを行ったところ，確かに遅い。 # HTML::FillInForm 1.06 Benchmark: HTML::FillInForm vs. HTML::FillInForm::Lite Rate fillinall_lite fillinall fillinpart_lite fillinpart fillinall_lite 570/s -- -52% -76% -78% fillinall 1199/s 110% -- -49% -54% fillinpart_lite 2349/s 312% 96% -- -9% fillinpart 2595/s 355% 116% 10% --ところで，このベンチマー
![[Perl]UTF8-flagged strings affects regexps with the "i" modifier - Islands in the byte stream (legacy)](https://cdn-ak-scissors.b.st-hatena.com/image/square/ca2670d1a43940f7464e1601df9e912af98cc4b9/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127143682567%2F17680117127143709749%2F1558186070)
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
モダンなXSの書き方 - Islands in the byte stream (legacy)
PerlのソースコードはPerl言語以上に変化が大きく，それに伴ってXSの書き方もだいぶ変わってきている。新しいAPIを使ったほうが可読性がよかったり高速だったり使いやすかったりする。 たとえば，スカラー(SV)から文字列(PV: pointer valueつまりchar*)を得るAPIの変遷は次のようになっている。 /* SV*からPVを得る古い書き方 */ STRLEN len; const char* pv = SvPV(pv, len); # pvとlen両方ほしいとき const char* pv_only = SvPV(pv, PL_na); # pvだけほしいとき /* その後SvPV_nolen()が追加され，PL_naはdeprecatedに */ const char* pv_only = SvPV_nolen(pv); /* 今は*_constが追加されたのでcons
__PACKAGE__がうざいときにuse component; - Islands in the byte stream (legacy)
DBIx::Classのシンタクスシュガーがほしいについて。とりあえずJifty::DBIとData::Modelについてはいずれ調べるとして，クラスメソッドのシンタクスシュガーを一般化するモジュールを書いた。 CPANにあげるようなものではないけど。 http://svn.coderepos.org/share/lang/perl/component package DB::Main::Artist; use component qw(DBIx::Class PK::Auto Core); table 'artist'; add_columns qw/ artistid name /; set_primary_key 'artistid'; has_many cds => 'DB::Main::CD'; 1; 内部でcaller()->load_components()してるだけなのでl
Perl/XSが得意なこと - Islands in the byte stream (legacy)
最近ひたすらXSを書いていて思ったのが，XSはやっぱり速いということ。 ただ，いつでも無条件に速いというわけでもなく，何も考えずに書くとPurePerlのコードより遅くなることも珍しくない。実際，最近書いたShikaやMOPのXS版もいきなり高速だったわけではなく，一番最初のコードはPurePerlのほうが10%-30%ほど高速だった。 いろいろベンチマークをとった結果の感触として，XSの得手・不得手が分かってきたのでメモしておく。ちなみに下記で「注意を払う」というのは内部で呼ばれるmalloc()を極力減らすという意味で使っている。SVの生成自体はmalloc()を伴わないことが多い*1が，文字列の生成/連結や配列の生成/push/unshiftでは内部でmalloc()が呼ばれる可能性が高く，速度を落とす原因となる。 得手分野 ループ - XSのループが早いというより，Perlのループ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
