No Such Blog or Diary

はてなっぽくかけるという NP_HatenaLike というプラグインを入れてみたのだけど， <pre> タグ内に空行（空白のみを含む）があるとその行で <pre> タグの効果を切られてしまう．でも &nbsp; を書き込んでおけば切られることはない．ということで，ソースを <pre> で囲むときに空行があるときは &nbsp; を書くようにした．

もうひとつ．Nucleus のDBバックアップを行うと，行頭に # がある行はバックアップ用スクリプト中のコメントとして扱われてしまい，データが吹き飛ぶことになる．Cのソースとかの場合 #include とかで先頭に # が来るため結構きつい．そこで，# を &#35; という風に文字参照に置き換えて書くようにした．

これらの条件の下，NP_SyntaxHighlighter を有効にしてみた．その結果，&#35; が # にならずに &#35; のままハイライティングされるようになってしまった．当然 &nbsp; もそのまま残って & だけに色がつくとかいう状況になった．原因は NP_SyntaxHighlighter がこれらの参照をうまく扱えないことにある．

ということで，NP_SyntaxHighlighter を少々書き換え． highlight_code の先頭付近で参照の置換をしている部分に必要な置換を追加．さらに， <pre> タグ直後に入ってしまう改行を回避．

$string = str_replace ( array ( '&quot;', '&apos;' , '&lt;' , '&gt;', '&apos;', '&#35;', '&nbsp;', '&amp;' ), array ( '"', "'", '<', '>', '?', '#', ' ', '&' ), $string );
$string = preg_replace('/^[ ]*[\n\r]/','', $string);

んで，重要なのが NP_SyntaxHighlighter の前に NP_HatenaLike を置くこと．NP_SyntaxHighlighter が &nbsp; を空白にしてしまうので逆向きだと <pre> が切れる．

とりあえずこれで大きく変な部分が解消された．あとはバックスラッシュが消えてしまう部分をどうにかすれば…

前の実験に使った TeX ソースでは，ソースが HDD にある場合と RAMDisk にある場合とで特に実行時間の差は見られなかった．そのため，前回の実験はソースを HDD において実行時間を計っていた．でも，ひょっとしたらソースが小さかったから差がなかったのかもしれない．ということで，もう少し大きなソースを持ってきて，pTeX のインストール先とソースの保存先とを変えつつ再実験してみた．

使った pTeX は角藤版の 2007/11/12 時点での最新バイナリ．余計なパッケージはインストールせず，ほぼ標準インストールの構成．

コンパイル対象のソースにはとある博士論文を使用．ソースは15分割くらいで，eps系の画像を55個くらいとリファレンスを250個くらい含む．コンパイル時間の計測は，metapost 9回，platex，jbibtex，platex，platex というコマンド列を全部実行した時間を計測．参考までに，TeX ソースの合計サイズが 700KB くらいで，metapost ソースの合計サイズが 160KB くらい．コンパイル時に生成されるファイル総数は75個で，内 68個が metapostの生成するファイルである．

まず，メインマシンでの結果は次のとおり（Core 2 Duo 2.4GHz, 4GB dualchannel memory (PC-6400), SATA 7200rpm HDD，Vista Business 32bit．pTeX と TeX ソースは別々のHDDにある）．

pTeX を RAMディスク上においた場合，ソースも RAMDsik に置いたほうが 0.1 ～ 0.2 秒程度速いかもしれない．逆に，pTeX を HDD に置いたときには RAMDisk にソース置いたほうがほんの僅かに遅くなるのかもしれない．でも，いずれの場合も意識するほど意味のある差とはいえないでしょう．

続いてW7Bでの実験結果は次のとおり（Core 2 Duo 1.06GHz, 2GB dualchannel memory (PC-4200), SATA 5400rpm HDD，Vista Business 32bit．pTeX と TeX ソースは同じHDDにある）．

こちらも傾向としては同じ．意識するほど意味のある差は見られない．残念．

結論：TeXソースをどこに置くかはどうでもいいんじゃないかと．

環境が変わるとどうなるかわからないけど，少なくとも自分の環境では RAMDisk においても HDD においてもコンパイル時間は変わらない．ただ，RAMDisk のほうが情報をロストする可能性が高いので，安全を考えると HDD に置いといたほうが良さげではある．

RAMDisk 上に pTeX をインストールして，HDDにインストールしたものとコンパイル時間を比較してみた．

コンパイルに使ったTeXソースは９分割されており，64KBくらいでA4に１４ページ（英語）ほど．ドキュメントクラスは article で，パッケージはfullpage, color, graphicx, amssymb, amsmath, cite を使用．画像は eps を６枚くらい．

コンパイル時間は，中間ファイルをすべて削除した状態から platex を３回かけた時間を time コマンドで測定（real）．ls-R データベースを作った場合と作らない場合とで測定．各セットについて１０回くらい走らせて平均を取った．

結果は以下のとおり．マシンはW7Bを使用（Core 2 Duo 1.06GHz, 2GB dualchannel memory (PC-4200), SATA 5400rpm HDD）．

とりあえず ls-R のあるなしにかかわらず RAMDisk のほうが速い．ls-R データベースがないときはRAMDiskのほうが30%程度速くそれなりに大きな差がついた気がする．でも，ls-R データベースがあると6%程度しか差が出ない上に絶対値も小さくなっているのでほとんど無視できる程度の差しか出なかった．

ちなみに，メインマシン（Core 2 Duo 2.4GHz, 4GB dualchannel memory (PC-6400), SATA 7200rpm HDD）だとRAMDisk と HDD で有意な差が出なかった．OSのディスクキャッシュが効いたのかHDDが速かったのかそれ以外なのかは不明．

結論：RAMDisk上にpTeXをインストールしてもあんまり特にならない．ls-Rデータベースを mktexlsr とかで作るほうが手間も要らずに速くなる．

まあ，OSのディスクキャッシュもあるのでリードアクセスだけのファイルを RAMDisk 上においておく事の意義はそれほどない気もする（RAMDiskのキャッシュをとられるとアホだ）．やっぱ書込みの激しいキャッシュとかに使うのが正しいのでしょう．

比較的近いけど入ったことなかったので散歩ついでに入ってきた．とりあえず東大関係者は身分証を見せれば入園料タダらしい．なんかいい写真でも取れるかと思ったけど時期的に無理っぽかった．というより，この時期にきれいなものが少なかったのと曇りかつ日が傾きすぎてたのとでだめだこりゃと．それでも利用者結構いたのは驚いた．

PlexTools Professional の Vista 対応が未だに行われないので PlexTools Professional LE をダウンロードして使うことにした．どこら辺が Limited Edition なのか全くわからないのだけど．とりあえずデータの読み書きが普通にできるらしいので今のところ LE で問題なさげ．

注文しておいた今日発売の Let'snote W7B が午後二時ごろ届いた．佐川急便で朝一で持ち出されたのに午後二時まで待たされるのはいつものこと．三時から秋葉原で輪講なのでセットアップは帰宅後までお預けになってしまった．で，以下セットアップして使ってみた感想．

まず気になるところ．ファンがうるさいときはうるさい．小型のファンなので高速回転し始めると高めの音が結構気になる．問答無用で低速回転設定にしたくなる．あと，W2 に比べてディスプレイ部分の外枠がやわらかくなっているので開くときの手の位置を気にしないと怖い．端を持ったときには結構ぐにゃりとする．

そんで以下はいいところ．まず，有線の Gigabit Ether 対応がうれしい．データの転送が速くて環境を移すのに助かる．Windowsのファイル共有での転送速度で 23MB/s まで出たので十分でしょう．そしてグラフィックの性能も W2 に比べたらものすごくよくなった．風神録が普通に動いてくれる．あとは処理速度自体が上がったのは当たり前として，メモリに SO-DIMM が使える&Dualchannelで動くようになったのもうれしい．まだ増設してないけどそのうち増やしましょう．

ところで，HDDのリカバリ用データの領域には具体的に何に関するデータが入っているのだろう？リカバリディスク自体は別に用意されているのだけど…　容量の関係なのだろうか？　とりあえず 2GB ほどなので気にしなければ気にならないけど HDD 換装時にどうなるのかが気になるところ．