PHPのunserializeとjson_decodeの速度を比較してみた
serialize後の文字列には長さが格納されている。一方、jsonは終端文字の検出が必要である。
そのため文字列が入っていた場合はunserializeの方が速いはず、という予想を立てて比較してみた。
数値の場合
配列に数値を格納。
10/100は10個の配列に100までの数を格納。
| 関数 | 10/100 | 100/10000 | 1000/1000000 |
| serialize | 0.002965 ms | 0.026016 ms | 0.175710 ms |
| unserialize | 0.002285 ms | 0.019043 ms | 0.139641 ms |
| json_encode | 0.001065 ms | 0.008745 ms | 0.045797 ms |
| json_decode | 0.002701 ms | 0.018625 ms | 0.192634 ms |
文字列の場合
連想配列に文字列を格納。
10/10は10個の配列に長さ10の文字列を格納。
| 関数 | 10/10 | 100/100 | 1000/100 | 100/1000 |
| serialize | 0.002051 ms | 0.023947 ms | 0.221336 ms | 0.078479 ms |
| unserialize | 0.002071 ms | 0.022763 ms | 0.335602 ms | 0.038826 ms |
| json_encode | 0.003094 ms | 0.112962 ms | 1.140379 ms | 0.961482 ms |
| json_decode | 0.004587 ms | 0.136636 ms | 1.447683 ms | 1.014543 ms |
環境はPHP 5.3.3-7+squeeze1 / core2duo E8600
予想通り、文字列の長さが長くなるほど、json_decodeよりunserializeの方が速かった。
ソース: https://github.com/firewood/test/blob/master/serialize_bench.php
WinDiffを少しだけ改良してみた
WinDiffは10年くらい使っていて慣れているのだが
という問題があった。
WinMerge使えばよいという話ではあるのだが、
- 何文字目から変化しているのか、ぱっと見わかりづらい
- 左右分割なので、diffっぽくない&桁数が減る
- 常に外部エディタで編集したい(右クリックメニューが遠い)
とかいう理由で、WinDiffを改造したほうが、慣れたインターフェースにできそうだったのでチャレンジ。
古いWinDiffはVisual C++ 6.0に付属していたような気がするが、これはバグっていて、右クリックメニューもない。
新しいものがPlatform SDKのサンプルに、SDKDiffという名前で付属していたので、これを使うことにした。
ちなみに最新版ではない(Vista用のものにはもっと細かいメニューがある)が、個人的には困っていない。
ライセンスについては、MSDNに「サンプルコードのうち、特記のないものはMICROSOFT LIMITED PUBLIC LICENSEに従う」という記述があったので、公開しても良いと判断した。
著作権表記と、プログラム名はそのままにする必要があるという認識です。
変更点は以下のとおり。処理はてきとーそのものです。
福島第一原発の水素爆発についてのメモ
原子力安全・保安院の会見を見てもよくわからなかったので、以下を見て理解した気になってみた。
- 3/18「福島原発事故の現状について」＠原子力情報資料室
- 福島第一原発で何が起きているのか
- 福島原発問題について（科学者の眼）
- MIT原子力理工学部による1、3号炉の水素爆発に関する解説
- 原発がどんなものか知ってほしい
- 福島第一原子力発電所 設備の概要
mingw版Groongaのビルド
Groongaをmingwでビルドしてみた。非公式ビルドが32bitだったので、64bit版にチャレンジ。※ Groongaは32bit OSをサポートしていません。
以下手順
MSys/MinGWインストール
- MinGWのインストーラをダウンロード
http://sourceforge.net/projects/mingw/files/ から mingw-get-inst-yyyymmdd.exe を取得する。 - インストーラを実行。オプションでMSysを追加しておく。
- http://sourceforge.net/projects/mingw-w64/files/ から Toolchains targetting Win64 / Personal Builds / sezero_20101003 を選択
- zipアーカイブをダウンロードして展開する。
ホストOSが32bitなら mingw-w64-bin_i686-mingw_20101003_sezero.zip
ホストOSが64bitなら mingw-w64-bin_x86_64-mingw_20101003_sezero.zip
※ 64bit版はネイティブコンパイラ(クロスコンパイラではない)なので、アーカイブ中のmingw64ディレクトリ以下をMinGWのルートディレクトリ(例えばC:\MinGW)に展開してもよい。 - MinGWのルートディレクトリに展開しなかった場合、mingw-w64-binを展開したフォルダをMSysのPATHに追加する。(下記参照)
MSysのPATHの追加方法
MSysのホームディレクトリに .profile というファイルを作成し、以下を記述。
※ アーカイブのmingw64ディレクトリを、MinGWのルートディレクトリに展開した場合
export PATH=/mingw/mingw64/bin:$PATH
Groongaビルド手順
- Groonga 1.1.0のpthread依存除去版 http://pub.cozmixng.org/~kou/archives/groonga-1.1.0.tar.gz を取得する。
※ 本来は http://groonga.org/download/ からダウンロードできます。次の肉の日(2011/3/29)以降。 - 64bitの場合、ltmain.shにパッチを当てる。(下記参照)
- MSysのコマンドプロンプトを開く。
- tar xf groonga-1.*.*.tar.gz によりGroongaを展開する。
- cd groonga-1.*.* で展開したディレクトリに移動する。
- 64bit OSの場合、引数なしで ./configure
- 32bit OSの場合、./configure --host=x86_64-w64-mingw32
- make
- make install
ltmain.shのパッチ
libtool 2.2に含まれるltmain.shはx86_64に未対応のため、2.4のものをバックポートする。
--- ltmain.sh.orig 2011-01-29 21:21:29 +0900 +++ ltmain.sh 2011-03-01 22:47:52 +0900 @@ -2560,7 +2560,7 @@ ;; *ar\ archive*) # could be an import, or static if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null | - $EGREP 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then + $EGREP 'file format (pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)' >/dev/null; then win32_nmres=`eval $NM -f posix -A $1 | $SED -n -e ' 1,100{
動作確認
残念ながら、64bit版は正常動作していないようです。まだ調べられていません。
参考情報
- ongaeshiさんとktouさんのtwitterのやりとり(http://togetter.com/li/102678)
- http://www44.atwiki.jp/ongaeshi/pages/14.html
キーを入れ替える7つの方法
ちょっと前になりますがWindows Internals勉強会というので発表してきました。
これ → http://www.slideshare.net/firewood/lr-5346579
以前「Vista/Windows 7におけるキーボードカスタマイズ問題」というのを読んで、これにフィルタドライバのネタを加えてみました。
で、発表時にid:NyaRuRuさんがMSKLCの紹介＆デモをしてくれたので、その部分を加筆しました。（こういうのがすぐ出てくるのがさすがだなあと思いました）
MinGW-ffmpeg
FFmpegのコンパイル (2010/4/2)を読んでffmpegをビルドした。
大変すばらしい情報なのだが手作業が多いのでスクリプトを書いてみた（github）。
以下手順。
- http://sourceforge.net/projects/mingw/files/ から MinGW-5.1.6.exe、MSYS-1.0.11.exe、msysDTK-1.0.1.exe をダウンロードしてインストールする。
- GCCを更新する。私は TDM's GCC/mingw32 Buildsにある4.3.3-tdm-1にした。（4.4以上は安定してるか不明だったので）
この際、別のバージョンのg++を入れていると間違ったlibstdc++がリンクされたりするので、/mingw/lib/libstdc++.* と /mingw/lib/libsupc++.* をどこかに退避しておく。
ffmpegだけビルドするなら3.4.5のままでも大丈夫かも。 - GCCを更新するとpthreadのライブラリとヘッダが更新されるので、退避しておく。
ファイルは /mingw/include/ の pthread.h、sched.h、semaphore.h と、/mingw/lib/ の libpthread*.a - coreutils-extを追加する。http://sourceforge.net/projects/mingw/files/MSYS%20coreutils/ にある coreutils-5.97-2-msys-1.0.11-ext.tar.lzma を、MSysの / に展開。
# cd / && tar xf coreutils-5.97-2-msys-1.0.11-ext.tar.lzma --lzma - wgetを追加する。http://sourceforge.net/projects/mingw/files/mingwPORT/Current%20Releases/ にある wget-1.9.1-mingwPORT.tar.bz2 を展開し、その中の wget.exeを /mingw/bin/ にコピーする。
- http://github.com/firewood/mingw-ffmpeg のスクリプトをどこか（/usr/src/ffmpeg/ とか）に置く。
- build.sh でダウンロードとビルドを行う。
# ./build.sh 2>&1 | tee build.log
なおffmpeg.exeを生成するだけでインストールはしないようになっているので、必要であればffmpeg.iniを編集する。（インストール先はPREBUILD1で指定し、インストールするかどうかをPOSTBUILD1で指定する）
また、faacを使用する場合は、faac.iniのENABLEDをyesにする。（これで生成したバイナリは配布できないので注意）
http://blog.k-tai-douga.com/article/36847657.html とはx264とffmpegのバージョンが若干異なっている。パッチが当たらないところはbuild.shの中で追加してある。
そもそも何でビルドしたかというと、
- 手持ちのデジカメがMotionJPEG対応なため変換することに
- 携帯動画変換君を使ってみようと思ったらffmpegが古かった
- ffmpegを更新したらオプションが色々変わっていた
- xvidを使おうとしたら Invalid pixel aspect ratio 0/1 というエラーが発生
という感じ。アスペクト比については無指定だとで0が入っていて、たぶん0は各CODECでよきに計らえという意味だと思うのだが、libxvidff.cは処理しないので困ったものだ。640×480の動画で明示的に-aspect 4:3としたときにsample_aspect_ratioに1:1が設定されたので同じにした。（PARなのだろう）
ビルド環境について
x264のオプションについて
ソフトウェアの社会的責任
夜フクロウと「社会的責任」を読んだ感想。
- ソフトウェアは基本的には何らかの条件に従って使用するものなので、例え無料であっても提供者と使用者が明示的に契約を結ぶことが望ましい。
- 有償無償に関わらずまずは契約を結ぶという考え方が共有されれば、堅苦しくはあるが、トラブルは減りそう。
- 責任という言葉は、何が義務なのかわかりづらい。社会的責任と、特定の機能を維持することとの間には、直接の因果関係はないのではないか。
- 契約書に何が義務なのか明示しておくべき。
- 責任という言葉は、セキュリティホールなど欠陥に対する義務という文脈で使われることが多い気がする。
- 開発者視点だと、対価を取った場合でも、対価にふさわしくない労力を提供する義務を課してほしくない。
- 製造者責任という言葉はある。何か問題が生じたときに、使用者だけでなく、製造者にも相応の責任があるという意味か。
- 社会的責任は社会に対する影響の大きさに比例しそう。提供者にはリスクがある。
