No Such Blog or Diary

Vista でうまくできない．どういう管理になってるんだ？　管理者権限のアカウントだけど管理者権限でプログラムを動かすにはどうすればいいんだろう？　いろいろと書込み禁止で作業できん…

何ヘルツの音まで聞こえるかを tone generator のソフトで試してみた．テレビの音 15kHz は普通に聞こえる．しばらく上げて 17kHz は聞こえる．18kHz くらいから怪しくなる．19kHzになるとある特定の角度に頭を傾けたときに感じるていど（聞くというレベルでなく）．20kHz も19kHzと同じ方向のみ頭を振れば変化が感じられる程度．まあ，スピーカの音を最大に引き上げれば聞こえなくもないけど体に悪そう．

「レッツノート プレミアム ファンブック」だそうで．モバイルNo.1予約宣言のキャンペーンの先着2000人に入ってたらしく送られてきた．今年がLet'snoteの10周年とのことで，そのための記念ファンブックらしい．とりあえず一通り読んでみたけど技術的なことはあまり詳しく載ってないので面白みにかけるような…．もう少し分解図とか載せてほしかった．あと軽量化のために苦労した点とかもっと詳しく．まあ，普通の人向けにはどうでもよいことだろうけど．

はてなっぽくかけるという 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のキャッシュをとられるとアホだ）．やっぱ書込みの激しいキャッシュとかに使うのが正しいのでしょう．