Movatterモバイル変換

Pythonista もls を読むべきか？藤原克則 @flyingfoozy

O 藤原克則(FUJIWARA Katsunori)O ホームページhttp://www.lares.dti.ne.jp/~foozy/index.ja.htmlO ブログhttp://d.hatena.ne.jp/flying-foozy/O Twitter@flyingfoozy

O 分散リポジトリ型履歴管理ツールMercurial の翻訳コミッタ／コントリビュータO Mercurial の hack に特化したなんちゃって Pythonista

O Solaris 上で稼働させるHPC 向けファイルシステムの実装などを仕事でやっていたこともO 「Tokyo OpenSolaris 勉強会」でSolarisカーネルの実装に関する勉強とかhttp://www.opensolaris.gr.jp/study.htmlO 下位レイヤの話も好き

執筆過程で見つけたバグの修正パッチがソースツリーに取り込まれた

GNU coreutils の ls はワシが育てた！（約1/4900）

Pythonista もls を読むべきか？

Pythonista:「os.listdir() を使うから読まなくても良くねぇ？」

例えばこんな感じ？import osfor e in os.listdir(path):fullpath = os.path.join(path, e)if os.path.isdir(fullpath):# ディレクトリに対する処理elif os.path.isfile(fullpath):# ファイルに対する処理.....

そんな実装ではスケールしない！！！

システムコール呼び出しコストO os.path.isdir(), os.path.isfile() ... は判定処理毎に lstat(2) 呼び出しO 呼び出し頻度は「要素数 × 平均的な if 判定数」O コンテキストスイッチを生じるので通常の関数呼び出しよりも圧倒的にコストが高い

多少コスト意識がある場合は….import os, statfor e in os.listdir(path):fullpath = os.path.join(path, e)st = os.lstat(fullpath)if stat.S_ISDIR(st.st_mode):# ディレクトリに対する処理elif stat.S_ISREG(st.st_mode)# ファイルに対する処理.....

それでも残る性能劣化要因

要因 (1) ～os.lstat() 呼び出しコストO os.listdir() は内部的に readdir(3) を使用O readdir(3) が返す struct dirent は要素種別情報 d_type を保持O 種別情報のみで事足りる場合os.lstat() 呼び出し自体が不要な筈（サイズや日時情報が必要ない場合等）

要因 (2) ～ファイル名解決コストO OS内部でのファイル名解決(ファイル名⇒対象の管理情報)はパス要素毎の繰り返し処理で実現O os.lstat() に指定されるファイル名にも同様の解決コストが必要

“foo/bar/baz/file” に対するOS内部でのファイル名解決例1.2.3.4.5.“.” への “foo” の問い合わせ“./foo" 相当の管理情報の取得“./foo” への “bar” の問い合わせ“./foo/bar” 相当の管理情報の取得“./foo/bar” への .......

ファイル名解決における直接的なコストO ディレクトリ階層の深さ⇒ 繰り返しによるコストの高低O 配下要素の多寡⇒ 要素有無の確認コストの高低O OS／ファイルシステム毎に色々な性能改善策(名前解決キャッシュ／木構造管理／ハッシュテーブル)O 運用回避e.g.ディレクトリ配下の要素数に上限を設ける(proxyサーバやブラウザのキャッシュ)

ファイル名解決における間接的なコストO 階層／配下要素の増加による I/O 量の増加O メモリアクセスと比べて、圧倒的にコストが高いO I/O 対象の散在によるシークコストの増加O 記録媒体が HDD であれば、ミリ秒単位の I/O 待ち状態O GHz クラスの CPU なら、単純計算でも百万命令単位分の I/O 待ち

低減策 (1) ～os.lstat() 呼び出しの低減O readdir(3) が返す struct dirent には各要素の種別情報を保持するd_type フィールドがあるO 種別情報のみで事足りるならlstat(2) 呼び出し自体が不要

低減策 (2) ～ファイル名解決コストの低減O fstatat(2) システムコールの利用O SYNOPSYSint fstatat(int dfd,const char *path, struct stat *buf,int flag);O 起点ディレクトリ(dfd)からの相対的名前解決O 直下の要素なら問い合わせは1階層限定O I/O対象を局所化可能

基本条件O 1.8GHz 4 core Atom 環境O I/O 要因での性能劣化を極力防止O メモリファイルシステム上でテストO 常に現ディレクトリからの相対アクセスO 必要なファイル／ディレクトリ要素のみ

lstat(2) 実行のコストO 実行条件O 1000 要素を保持するディレクトリO 1000 要素それぞれへの lstat(2) 実施O 計測結果O 1000 回繰り返しで 3 ～ 4 秒の違いO lstat(2) 実行コストは1回あたり 3 usec ～ 4 usec

ファイル名解決のコストO 実行条件O 現ディレクトリから 10 階層隔てるO 1000 要素を保持するディレクトリO 1000 要素それぞれへのlstat(2) または fstatat(2) 実施O 計測結果O 1000 回繰り返し時に 6 ～ 7 秒の違いO lstat(2) と fstatat(2) のコスト差は1階層あたり 0.6 usec ～ 0.7 usec

性能計測の評価O 対象10,000超で体感的な差が出る可能性O システムコールのコスト差だけでも対象1,000,000なら数秒オーダーの差O 実際の環境では、性能劣化要因が増えるO ディレクトリ階層が複雑化した場合ファイル名解決コストの増加O HDD上のファイルシステムの場合シーク発生による I/O待ちの増加

環境毎の仕様準拠O dirent.d_type による種別情報の提供はPOSIX 標準ではオプション扱いO GNU coreutils の ls でも使用可能な環境では使用O fstatat(2) の標準化は XPG7 (2013) からO XPG7 非準拠なら、サポートの必要無し（とは言うものの多くの環境で利用可能）O GNU coreutils の ls では未使用

Python からの利用可能性O Python の標準 API からはdirent.d_type も fstatat(2) も使えない

Python から使えないならそんな話するな！

そんな時の為のC ライブラリ連携！

Mercurial におけるlistdir() の独自実装

まーきゅりあるノ話ヲシタイダケデハナイデスヨ？(棒)

O ディレクトリ配下要素の情報取得を行う機能 osutil.listdir() をMercurialではCライブラリとして独自実装O システムコール実行コストを環境に応じて極力低減O DT_REG マクロ判定(dirent.d_type 利用の可否)O AT_SYMLINK_NOFOLLOW マクロ判定(fstatat(2) 利用の可否)O Cライブラリ連携を使用できない環境向けにpure Python 版 osutil もあるが性能的には当然Cライブラリ実装よりも遅い

ls.c は読まなくても….O mercurial/osutil.c の listdir() 実装は読んでおいた方が良いかもね！O ディレクトリ要素や要素毎情報の取得で使用している API を把握しようO API 使い分けによる性能への影響を理解しようO POSIX環境向けと Windows環境向け実装が同一ファイル中にあるので参照時は注意

Pythonista も….O 「lsを読まずにプログラマを名乗るな！」を買ってね！O OS の内部処理とかファイルシステム周りの話も盛り込んであるよ！

MercurialO プロジェクトページhttp://mercurial.selenic.com/O mercurial/osutil.chttp://selenic.com/repo/hg/file/stable/mercurial/osutil.cO mercurial/pure/osutil.pyhttp://selenic.com/repo/hg/file/stable/mercurial/pure/osutil.py

POSIX仕様O XPG6: IEEE Std 1003.1, 2004 Editionhttp://pubs.opengroup.org/onlinepubs/9699919799/O XPG7: IEEE Std 1003.1, 2013 Editionhttp://pubs.opengroup.org/onlinepubs/009695399/

GNU coreutilsO プロジェクトページhttp://www.gnu.org/software/coreutils/O src/ls.chttp://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c

「lsを読まずにプログラマを名乗るな！」O 書籍情報http://www.shuwasystem.co.jp/products/7980html/3943.htmlO サポートページhttp://www.lares.dti.ne.jp/~foozy/fujiguruma/ls-src/index.html

Movatterモバイル変換

Change Language

Pythonista も ls を読むべきか？

Embed presentation

Recommended

More Related Content

What's hot

Similar to Pythonista も ls を読むべきか？

Pythonista も ls を読むべきか？