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
each()は遅い上に微妙な問題も起きやすい - Islands in the byte stream (legacy)
特別な条件がないかぎり、each()は使うべきではありません。代わりにkeys()/values()を使うべきです。その理由は2つあります。 each()は遅い each()でハッシュ全体をループするのは遅いです。これは、keys()/values()がその内部の値をそのまま参照する*1のに対し、each()は代入しないとその値を使えないからです。 ベンチマーク： #!perl use strict; use warnings; use Benchmark qw(cmpthese); my %hash = map { $_ => $_ } ( 1 .. 10000 ); cmpthese -1, { each_k => sub { while(my $key = each %hash) { } }, each_kv => sub { while(my($key, $value) = eac
Islands in the byte stream
大チェッカーすばらしい。こういうのがほしかった。 Mobile Application Development なおフィードはだれでも追加できるようにしてあります。 http://central.sonatype.org/articles/2014/Oct/28/enforcing-valid-dependency-versions/ 2014年10月の話ですが、これのせいで手元のライブラリのアップロードが失敗するようになってました。これからは、依存ライブラリのバージョンは "3.+" ではなく"[3,4)" （3以上4未満）などのような数学的範囲表記（mathematical range syntax）をしなければならない、ということです。詳しくは上記エントリを参照のこと。 変更例： https://github.com/gfx/android-power-assert-plugin/c
「優れたPerlプログラマを見分ける27の質問」の日本語訳 - Islands in the byte stream (legacy)
(追記あり) How to Identify a Good Perl Programmer (by chromatic) が面白かった*1ので、27の質問を訳してみました。chromatic氏によれば、いずれも単純明快な質問でPerlの哲学や特徴をよく現しており、優れたPerlプログラマであれば少なくとも80%は答えられるべきだそうです*2。あなたは全ての質問に答えられますか？ Perl5において変数のシジル*3が示すものは何か 配列のアクセスする際の $items[$index] と @items[$index] の違いは何か == と eq の違いは何か ハッシュをリストコンテキストで評価すると得られるものは何か Perlドキュメントからキーワードを検索するにはどのようにするのか Perl5における関数とメソッドの違いは何か Perl5が変数のメモリを再利用するのはいつか 変数のスコー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
