airheadさんのトモダチの日記、みんなの日記も見てね。 アナウンス：スラドとOSDNは受け入れ先を募集中です。
「ハック」という言葉について皆さんそれぞれ定義をお持ちでしょうが、私の場合は「Eddieがギターにしてきたこと」という感じでした。ハードウェアにしても、演奏スタイルにしても。
そういう意味なら一番はあの人だ、いやあの人だ…と様々な名前が挙がりそうですが、まあEddieならあまり文句は出ないでしょう、ねえ。という感じ。
故人の信仰にはお構いなしに、こっちの作法で勝手に追悼いたします。合掌。
症状：一切の音が出ない。音量コントロールいじった時の確認音も出ない。メディアプレーヤー再生でエラー。これはどれほど関係しているのかわからないが、Webストリーミング再生では、ブラウザとサイトの組み合わせによってエラーが出る。
解決法：ドライバを入れなおす。普通過ぎてちょっと恥ずかしい。同時にメディアプレーヤやブラウザの症状も回復したので、やはりサウンドドライバが原因だったのかもしれないが確証はない。
ただしIEだけは、他が復調後も「ほぼ」復調といったところ。YouTubeを再生できるようになり音も出るが、しばらくすると固まることがある、らじるらじるでは相変わらず再生ウィンドウ開いた時点で固まり、再生までこぎつけない、といった具合。サウンドドライバ以外に原因があるのか不明。また気が向いたときに調べてみようと思う。
以下、未解決時の症状を残しておく。
親愛なる殿下へ
私はまだ死にたくないし、死を恐れながら生き続けて、最期までジタバタしするのが私にふさわしいと思っています。いま私の国で起こっていることも、いろんなことを考えさせます。しかし貴方がまだまだいろんな所へ連れて行ってくれると思っていた私の、いまの気持ちは、
I don't care, pretty baby,
just take me with U.
Take Me With U / Prince
な感じです。悪戯が過ぎますよ、殿下。
私が憶えていた円周率の語呂合わせは下のようなやつ。小数点以下30桁までで、得られる円周率は真の値よりわずかに小さく、その差 1e-30 未満。
みひとつ よひとつ いくに むいみ いわくなく みふみやよむ じむしさんざん やみになく
3.14159 26535 89793 23846 26433 83279 ...
一方で、観測可能な宇宙の直径は約 8.8e26[m] らしい。ちょうど 8.8e26[m] だったとして、上の記憶法で宇宙一周の長さを出したときの誤差は 8.8e-4[m] = 0.88[mm] 未満となる。意外と身近な長さにびっくり。今後「宇宙を救うために一周する紐が要るから、長さを計算してくれ」とか頼まれることがあっても、まあ2、3mmオマケしておけばなんとかなるだろう。
というか、さっき思いついたからといって、わざわざ15時まで待って投稿するほどの話じゃないな。
ギターマガジンをスキャン中。100冊以上あるのかな。最初は楽勝かと思ってたが、結構しんどくなってきたので、息抜きにメモ。
スキャナはHPの複合機、ソフトはIrfanView。本はばらさず、グレースケール300dpiでスキャン、PNGでページあたり5.5～6.0MB。ページ替えなどテキパキやって1ページ20秒ぐらいか。同じくカラーだと10～11MB、スキャン時間も倍ぐらいかかるので、カラーページもほとんどグレースケールで。リンダ・マンザー作「ピカソ・ギター」の写真はさすがにカラーで取っといた。
譜面中心、GM Selectionsは全部取っとくつもりだが、Feartured Guitaristsや特集は8割程度。取り上げる程かなと当時も疑問だったバンドとか、二三年おきに出てくる運指トレ特集とか、もういいや。インタビューのみとか、後半ページの連載セミナーはいらない。買いだした頃のように隅々まで熱心に読むことはないし、取っといても結局読まないだろう。興味があればテーマごとにまとめた教則本でも買ったほうがいいような気がする。で、1号あたり60ページぐらい。
手に取って読んでるうちは大して気にならなかったが、印刷の傾きがひどいページが多い。ほとんどが時計回り、角度にして最大でも1度ぐらいだが、その場合8分音符主体の2小節進むと五線譜の線1本分下がっていたりする有様で、画面越しでは相当気になる。スキャンしているのは中綴じの本の前半が主だが、開いて左側のページのほうが大きく傾いてるページが多い。一貫して癖があるのならまだいいが、ときどき大きく傾いたりほぼ水平になったりしている。製本について詳しいわけじゃないが、これぐらい普通で全然問題にならない、のだろうか。
綴じ部分で破れて表紙外れかけのやつは、まずスキャンする記事のない裏表紙側の根元上下をバインダークリップで固定すると楽。気づくまで時間がかかったが。
それにしてもCHARと布袋寅泰の登場回数の多さよ。あくまで印象だが、数号おきに布袋CHAR布袋CHAR渡辺香津美って感じ。そういえば『クロスロード』のリフとか『天国への階段』のイントロ＋ソロとかにしても、もう5回ぐらいスキャンしている気がする。『ハイウェイ・スター』は2回ぐらい？ 意外だ。
本題ではないのでプレーの説明は省くが、きっかけは「チャック・タナー・プレー」だった。ずいぶん前のことだが、アメリカでもそう呼ばれているのだろうかと疑問に思って、いろいろ検索してみたことがあった。なかなかそれらしいものが見つからないので、当時広島にいたブラウン監督とリブジーとの間ではそれで通じていただけだろうか、などと思い始めたさなか、新聞記事アーカイブサイトでおかしな試合の記事を見つけた。
そのときは登録せずに試し読みできたように思うが、現在はクレジットカード番号も登録せねばならず、トライアル期間が終わると有料プランに移行で解約には手続きが必要と面倒なことになっているので、今回確認はしていない。だが確か、そのAP通信の配信記事は次のような書き出しだったと思う。
9人の男たちが内野を守った。打者毎に外野手は守備位置を交換した。回が進むにつれ、試合は奇妙な方向へ転がって行った。
外野手を一人内野に回すのは最近の日本のプロ野球でも何度かあったように思うが、「9人内野」ともなると漫画『ONE OUTS』のエピソード以外では聞いたことがない。それ以外にも様々なことが起こったこの試合を記録しておこうと思う。日本球界に縁のあった人も案外いたので、人名はなるべく日本語版Wikipediaにリンクするようにした。1985年4月28日(日)、シェイ・スタジアムで行われたメッツ-パイレーツ戦である。
回を追って記していこう。1回表パイレーツの攻撃。先頭のジョー・オーソラックがヒットで出塁するも盗塁失敗、続くジョニー・レイもヒットで出塁するも牽制死、ビル・マドロック三振と、三人で終わってしまう。その裏メッツの攻撃。先頭のウォーリー・バックマンは一飛に打ち取られるも、そこから単打・四球・四球で満塁としたところでダリル・ストロベリーの6号本塁打、彼にとってはメジャー昇格後初の満塁弾が飛び出す。後続は抑えられて4対0。
あまりにも対照的な1回の表裏である。NYタイムズ紙の記事では日曜日の試合とストロベリーの名とデザートとを掛けたのだろうか、「Super Sundae started sweetly」とも書いているが、試合の雲行きはすぐに怪しくなっていく。1回の後続だけでなくその後もメッツからのヒットが出なくなってしまうのだ。5回裏には四球とエラーで二死一三塁のチャンスをつかむが、結局追加点は奪えない。一方のパイレーツは2回表にジョージ・ヘンドリックの本塁打で1点返すと、6回表には一死からマドロック、 ジェイソン・トンプソンの連続二塁打でもう1点、三振を挟んでトニー・ペーニャの本塁打で、ついに4対4の同点に追いつく。その後も連続単打で攻め立てるも、代打ジム・モリソンが遊飛に倒れてこの回は同点どまり。
こう書くとパイレーツがめげずにヒットを重ねていくうちについに追いついたようにも見えるが、そういうわけでもない。3回から5回まではパイレーツにもヒットが出ていないし、両軍とも時々四球やエラーで走者を出すものの、まるで活かせていない。6回裏をメッツが当たり前のように三者凡退すると、両軍ともこの調子で…いや、7回表マドロックが単打で出塁している。だが、それだけだった。何事もなく7回が終了し、8回などは両軍で示し合わせたかのようなチャンスの潰し方をしている。表のパイレーツの攻撃。四球、6-4-3の併殺、四球、左飛でチェンジ。裏のメッツの攻撃。四球、遊ゴロで一死二塁、敬遠、遊ゴロで二死二三塁、敬遠、左飛でチェンジ。
9回表パイレーツの攻撃。先頭のラファエル・ベリアードが単打で出塁したところで事件が起きる。次打者ダグ・フロベルへの投球前、一塁手キース・ヘルナンデスの、バントに備え本塁方向へチャージしかけた後に牽制球を受けるため一塁に戻るという一連の動作でボークを取られ、走者二塁へ。一塁手に対してのボークという判定にメッツ側が納得するはずもなく、以降メッツからの提訴試合として続行となった。直後の連続四球で無死満塁となったところでジェシー・オロスコが救援登板する。レイを三振、マドロックをショートライナーで二死までこぎつけるが、次打者トンプソンの打席で捕手ゲーリー・カーターが投球を後逸してしまう。ここで三走ベリアードが本塁突入を試みるもカーターが見事なバックハンドフリップで送球、カバーに入ったオロスコにボールが渡ってタッチアウト、無得点。やはりヒットは続かない。
9回裏メッツの攻撃。この回は7番から始まり、9番の投手オロスコにも打順が回る。打順としては最悪だが、一死からラファエル・サンタナがエラーで出塁、一気に二塁まで進む。さらにオロスコの二ゴロの間に三塁に進み、二死ながらもサヨナラのお膳立てができた。しかし1番バックマンが遊ゴロ、延長戦へ。ちなみにメッツは満塁弾の後、一本のヒットも放っていない。
10回表。二塁打と敬遠で一死一二塁のチャンスを作るも次は7番。ここからパイレーツは代打策で勝ち越しを狙う。7番への代打シクスト・レスカーノは右飛。続く代打ビル・アルモンが左前打を放つも、本塁を狙った二走ヘンドリックがタッチアウト。これは両軍合わせて7人目、パイレーツだけでも4人目の代打にしてようやく出たヒットだが、それも実らなかった。この後11回裏まで両軍とも三者凡退を重ねる。
12回表に入り、メッツ監督デイビー・ジョンソンが動く。前の回7番まで打順が巡ったことを踏まえて、7番に投手トム・ゴーマンを入れ、9番にラスティ・スタウブを入れて右翼に就かせた。この時スタウブは41歳で23年目の大ベテラン、もともと上手くない守備に就くのも83年6月22日以来、ほとんど2年ぶりだった。冒頭に記した、打者毎に守備位置を交換した外野手とは彼のことで、この後右打者のときは右翼、左打者のときは左翼に就いた。『Amazing Mets Trivia』なる本の彼の項でも採りあげられ、「ともに守備位置を入れ替えた外野手は誰でしょう？」とある（答え：この時点で左翼のクリント・ハードル）。ゴーマンがパイレーツの攻撃を封じると、試合の流れにも微妙な変化をもたらしたようだ。
12回裏メッツの攻撃。先頭の8番サンタナが単打。メッツ打線としては1回の満塁弾以来のヒットで出塁すると、入ったばかりのスタウブが二塁打を放ち無死二三塁、打順は1番バックマン。何ともあっさりと、絶好のサヨナラ機が訪れる。これに対しパイレーツ監督チャック・タナーの執った策が、スクイズに備えて全ての外野手を内野に配置するという「9人内野」である。残念ながらこの隊形がどの打者まで続いたのか記事やボックススコアには詳しく記録されていないが、バックマンが歩いて無死満塁、レイ・ナイトを6-2-3の併殺、カーターを遊飛と、この絶体絶命の状況を切り抜けてしまった。
これがまた試合の流れを変えたのか、13回以降、両軍ともに凡打の山を築くことになる。唯一、12回裏のお返しとばかりに泥臭い展開になったのが、14回表パイレーツの攻撃。この回は9番、とはいってもスタウブと同じく投手野手の打順を入れ替えての途中出場の、フロベルから上位に巡る打順となる。単打・犠打・単打で一死一三塁としたところで、3番マドロックは三ゴロ、フロベルが本塁を突くもタッチアウト。4番トンプソンの打席でゴーマン暴投で二死二三塁、トンプソン歩いて満塁とするも、そこまで。5番ヘンドリックのファールフライを捕手カーターが（おそらく観客席に身を乗り出して）好捕しチェンジ。その裏の14回裏から17回裏までは、両軍ともに交代もほとんどない。ベンチ入り選手を使い切る寸前での我慢比べだったのだろう、ともにヒット1本ずつという苦行になってしまう。
こうして迎えた18回表、パイレーツの攻撃。流れの変化が不意に訪れる。12回表にマウンドに登ってから無失点を続けていたゴーマンは、二死一塁で久々の代打を迎えた。投手ながら打撃の良さでしばしば代打起用もされていたという、リック・ローデンである。右打者ローデンを受けてスタウブは右翼に就くも、ローデンの放った緩い飛球が右翼線を襲う。一走の長駆ホームインもあり得る場面で「俊足とは言ってもらえないだろうけどね、全力で走ったよ。彼が打った瞬間、絶対に捕ってやるって思った（スタウブ）」。お粗末守備で2年ぶりに守ったスタウブがパイレーツの久々の得点機を、膝下の高さに差し出したグラブで見事に摘み取ってしまったのである。
18回裏メッツの攻撃。両監督とも、この回を最後の山場と見ていたようだ。攻撃が始まる前、タナー監督は守備要員・位置の変更を告げた。先頭のカーターが四球で出塁すると、ジョンソン監督は代走ムーキー・ウィルソンを告げた。ストロベリーが満塁弾以来のヒットで無死一三塁として、6番ハードル、7番は7回零封のゴーマンに打順が巡る。ここに代打を送るべく、ジョンソン監督はジョージ・フォスターに準備をさせていた。「最後の切り札は切ってたよ（ジョンソン）」。というのも、ここでゴーマンに代打を出しても試合を決めきれなかった場合、2日前の同カードで先発し9回完投（完封）していたロン・ダーリングを登板させざるを得なかったのである。
だがまずは6番ハードルだ。彼の放った打球は一塁手トンプソンの正面を突いた。そしてそのまま、トンプソンの股間を抜けていった。メッツが相手でこの大事な場面に痛恨のトンネルエラー、どこかで聞いたような話である。それはさておき三走ウィルソンが還り、ゲームセット。メッツ 5-4 パイレーツ、勝：トム・ゴーマン、敗：リー・タネル、試合時間5時間21分。36,423人の観客をも巻き込んだ大苦行大会は、何ともあっけなく終わった。
ボックススコアで見ると凡打の山の貧打戦にも見えるが、その裏側には両軍の粘りの投球とそれを支えた好守備があり、良い意味での珍采配があった。間違いなく野球の酸いも甘いも詰まった一戦であり、記事で展開を追っていくだけでも面白い。その中でも多くの分量を割かれている12回から出場した殊勲の2人、ゴーマンとスタウブについて、その後も含めて触れておこう。
ゴーマンは6番手として登板し、試合終了までの7回打者25人を無失点に抑えた。彼の個人成績を見ると83年からリリーフ陣の一角に定着していたようだが、この年限りでメッツを去っており、その後フィリーズ、パドレスでの2年間でも目だった成績を残せていない。この登板は彼のキャリアの最後の輝きの一つになってしまったのかも知れないが、記録は残るものだ。2001年、メッツに在籍していたディッキー・ゴンザレスが6回2/3無失点の好リリーフで勝利投手になったときにも「85年のゴーマン以来」と引き合いに出されている。一方のスタウブ、彼のハードルとの守備位置交換は結局11回にも及んだ。一番打球がこないだろう場所へと動かし続けていたところ、ついに難しい打球が飛んでくるも好捕。スタウブの85年の守備機会はこの1回だけで、この年限りで引退した彼の最後の守備となった。
話はそれるが、これについても触れないわけにはいかないだろう。苦労の末に勝利してナ・リーグ東地区首位に並んだメッツだったが、翌日29日のNYデイリーニューズ紙の一面では、ア・リーグ東地区最下位のヤンキース絡みの話題の、オマケ扱いになってしまっていた。NYタイムズ紙によれば大観衆が声援を送るものの「無料のチョコサンデー（おそらく満塁弾のこと）」以外で一番盛り上がったのは、試合中の場内に伝えられたこの速報へのブーイングだったという。
ちょうど同じ28日、ヤンキースのオーナー、ジョージ・スタインブレナーが監督のヨギ・ベラをわずか16試合で解任、ビリー・マーチンを後任としたのである。前日には監督解任を決めていたというスタインブレナーがGMに伝えたのは16試合目のホワイトソックス戦4回途中、1-1の同点の時点とのことだが、ヤンキースはこの試合にもサヨナラ負けして同カード3連敗、10勝16敗で最下位をひた走っていた。
ヤンキースの話で締めるのもどうかと思うので、メッツ-パイレーツ戦に話を戻して、LAタイムズ紙の記事にならってチャック・タナーの試合後の談話で締めよう。30年前の試合を調べなおす気になったのも、これにシビレたからだし。
常に楽観的なパイレーツ監督チャック・タナーは、.224のパイレーツ打線が18本のヒットを重ねていたことを頼みの綱にしていた。
「あれこそ、ひっくり返さにゃならん試合ってやつだな」と彼は言う。「うちはバットが振れていたしね。事が起こる兆しってやつだ。ケチが付いたとしたら、あのスタウブのキャッチだけだろうな。俺はヒットになるって確信したんだけどなあ。あれはまったく、大したキャッチだった。もしこれがワールドシリーズだったら、30年は語り草になっただろうよ。」
米アップルが2007年1月にスマートフォン「iPhone」を発表する以前、韓国のサムスン電子とLG電子の携帯電話端末のデザインを参考にしていた事実が米裁判所が公開したアップルの内部文書で明らかになった。米裁判所はこの文書が存在しているにもかかわらず、サムスンがアップルのiPhoneを模倣したと判決している。今後欧州や他の国々での訴訟にどんな影響を与えるか注目される。
4日に公開されたアップルの内部資料は「3GSM展示会分析」と題するもので、アップルは2006年初めにスペインで開かれた国際見本市「3GSM」に出展されたサムスン電子、LG電子、ノキア、モトローラ、ソニーエリクソンの製品のデザイン、機能を詳細に分析する内容だ。対象品目はサムスン電子「F700」、LG電子「プラダ・KE850」、モトローラ「モトQ」、ノキア「N77」などだ。その翌年、アップルはiPhoneの初代モデルを発表した。
ここに書かれている「アップルの内部文書」は、合衆国連邦地裁カリフォルニア北地区でのアップル対サムスン裁判で裁判所提出された、被告サムスンの証拠 NO. 2627.001-051 と思われる（朝鮮日報の画像は同証拠26ページの一部をモノクロにしたもののようだ）。これがなかなかスゴイ。
表紙(1ページ)左上にアップルロゴがあり、社名 Apple Inc. および機密扱いを示す表示はない。表紙を除く全てのページでは左下にアップルロゴ、右上に「CONFIDENTIAL（機密）」、右下に「Apple Confidential（アップル外秘）」とある。3ページには機密扱いについての注意書きがあり、それっぽいイラストが入っている。個人的にはなんだかこのイラスト、アップルらしくない/大企業の重要文書らしくないように思えるが。
すべてのページに「3GSM World Congress 12-15 Feb 2006 Barcelona」と開催期間が入っている（「月日,年」とする米国で一般的な日付表記順ではない）。が、3GSM World Congress 2006 の開催期間は Feb 13-16, 2006 、同2007 は Feb 12-15, 2007 だった。GSMArena.comによる2007のレポートのタイトルにあった単純な編集ミス 「3GSM Barcelona 2007 live coverage GSMArena team, 12 - 15 Feb 2006.」 を丸写ししただけのようにも思える。
内容は技術系メディアが報じるレポートの要約といった域を出ず、機密扱いにする必然性は見られない。9,10ページ全面を占める、荒くて何のプレゼンだかよくわからない画像は、PDFからコピーしてみればわかるが180x135ピクセルの小さなもの。出処は分からないが、どこかのウェブサイトの記事内のサムネイル画像っぽい。
ところどころに業界の2006年の実績と2007年の展望がみられる。11ページにはDRMに関する動きについてまとめてあり、Steve Jobsの「thoughts on music」(Feb 6, 2007) が業界内で大議論を呼んだことや、BBCの Feb 15, 2007 の記事のURLまで書かれている。幾つか抜き出して調べただけで全部調べたわけではないが、サムスンを含む出展各社の製品は2007年発表のもののようだ。2006年2月であれば全く現実味のない「Available Q2 2007, price around 450€（2007年第2四半期に販売開始、予価450ユーロ前後」といった表記もあった。
...ええと、とりあえず、1年後を見事に予見したスゴイ文書！ さすがアップル！！ ということにしておこう！！！
タスクバー（ジャンプリスト）とスタートメニューの「いつも表示」「最近使ったもの」は共通で、アプリごとに下のフォルダ内のファイルに格納されている。
%AppData%\Microsoft\Windows\Recent\AutomaticDestinations
%AppData%\Microsoft\Windows\Recent\CustomDestinations
この2つのフォルダは、ExplolerではRecentフォルダを開いても見えないが、表示が抑止されているだけで特別な属性は付いてない。dirコマンドでは表示される。Explolerでも上記パスをアドレスバーに入れれば表示される。
それぞれのフォルダに入っている以下のファイルがリスト情報を格納している。ファイル名の16進数がキーとなってアプリごとに対応している。「いつも表示」の項目も拡張子automatic...のほうに入っているようだ。拡張子custom...はWin7対応アプリでのリスト拡張のためだろうか（IE8・WMP・Operaなど）。
16桁の16進数.automaticDestinations-ms
16桁の16進数.customDestinations-ms
（Recentフォルダで dir /s *.*-ms で全表示）
ファイルの属性を読み取り専用にすれば、そのアプリのみリスト項目が無効になるようだ。たとえば読み取り専用で自動更新停止、隠しファイルで無効とするほうが合っているような気がするが、隠しファイルにしても動作は変わらないので、意図せぬ動作かもしれない。再ログオンなどでのExplorer再起動は不要。読み取り専用を解除すると無効前のリスト項目が復帰する。無効時の動作は以下のとおり。
キーとアプリの対応の調べ方は面倒。リストが更新される操作を行って、ファイルの更新日時であたりをつけて、それらしいファイルを別フォルダに移動して、リストの動作を確認、という手順をとった。もっと簡単な方法があるかもしれないけど不明。以下は手元の環境 Windows 7 Pro X64 で確認したもの。
Explorer
1b4dd67f29cb1962
EmEditor Free (C:\Program Files (x86)\EmEditor\EmEditor.exe)
84d2723ef5ccceb8
1b4dd67f29cb1962 でウェブ検索したら関連記事が出てきたので、個別の環境に依存しないようだ。標準的なインストールで一定になる実行ファイルのフルパスのハッシュをキーにしている、とかだろうか。
リングノードベンチマーク - どう書く？org から。せっかくなので値の受け渡し方法を変えてみたり（list 1-4, 5, 6、doukaku.orgに投稿したのはlist 4）、いろいろな条件で計測してみたりしたところ、ブラウザの傾向が垣間見えて面白かった。調子に乗って、5回計測して平均を取るまでしてしまった。
(07/12 13:30 追記) list 6を追加
n*m = 1000*1000
list1 list2 list3 list4
---------------------------------------
FF3.5.0
old 7521 4264 1670 1608
new 4262 3369 1459 1403
FF3.5.0 safemode
old 1936 1077 1311 1346
new 1805 992 1458 1397
Op 9.64 2047 869 767 615
Op 10b 2003 878 709 631
IE 6 19238 5106 5544 5240 [ms]
Window 2000 + Pen4 2.53GHz
Firefoxにおいて、oldとあるのは現在常用しているプロファイルでの、newは新規プロファイルでの実行結果。常用プロファイルはFireBugなどアドオンが数多く入っているが、FireBugを無効にするだけで新規プロファイルとほぼ同等まで改善する（FireBugのページごとのオンオフのUIで無効にするのではなく、アドオンマネージャでFireBugを無効にする必要がある）。FireBugは他のアドオンのエラーを検出することもあるが、そうした動作が影響しているのかもしれない。
セーフモードではさらに速度が向上するが、この理由はよくわからない。通常モードにおいてアドオンマネージャで拡張・プラグインをすべて無効にしても、セーフモードほどの数値は出なかった。
Operaでは、Firefoxの通常モードの倍以上速い数値が出たが、総ノード数を大きくしていくに従ってのオブジェクト生成の速度低下がFirefoxよりも顕著である（下表create）。ただし一旦生成してしまえば、ノードのオブジェクト呼び出しにおける速度低下はまったくといってよいほど見られない（下表call）。
n*m 5e4*20 1e5*10 5e5*2 1e6*1
---------------------------------------
FF3.5.0 new
create 143 284 1583 3765
call 1514 1559 1616 1631
Op 10b
create 210 462 5281 16750
call 784 772 781 784
list1-4ではノードを配列に格納しているが、配列の大きさによる影響は思いのほか少ないないようだ。list5のように、参照を張ることのみでオブジェクトを維持して巨大配列の生成を回避しても、速度低下を大きく改善することはできなかった。総オブジェクト数に依存しての速度低下だろうが、100万もオブジェクトを生成することはまれだろうし（200-250MBもメモリを消費する）、問題になることは少ないだろう。
書き忘れていたlist 6を追加した。もっとも素直に実装すればこの形になるかと思うが、オブジェクトにプロパティmsgがつき、若干ではあるがlist 3よりも遅くなる。
ノードを表すオブジェクトのメソッド (receive) が次のノードのメソッドを呼んでいくと、関数スタックがたまりすぎてしまう。ここでは配達人役の関数sendを用意し、メッセージを引数としてノードのメソッドを呼び、戻り値として次のノードへの参照と次に渡すメッセージ（通常は引数として受け取ったメッセージそのまま）を受け取る形にした。規定周回数に達したらメソッドreceiveはfalseを返し、それを受け取った関数sendは処理を終了する。
list 1-4で、sendに参照とメッセージを返す方法を変えている。list 1ではreceive内で参照とメッセージを束ねたオブジェクトを毎回生成している。
// list 1
var send = function (dest, msg) {
var relay;
while (relay = dest.receive(msg)) {
dest = relay.dest;
msg = relay.msg;
}
return msg;
};
var Node = function () {
var id = 0;
return function () {
this.id = id++;
this.dest = this;
this.receive = function (msg) {
if (typeof this.count == "number") {
if (this.count == 0) return false;
this.count--;
}
return {dest: this.dest, msg: msg};
};
};
}();
var n = 1000, m = 1000;
var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
ring[i] = new Node();
ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;
var t = new Date();
var lastMsg = send(ring[0], "read me in turn.");
t = new Date() - t;
alert("elapsed time:\n" + t + "[ms]\n\nmessage:\n" + lastMsg);
list 2ではsend内でオブジェクトを用意しておき、各receiveがそこに書き込むようにして一つのオブジェクトを使いまわしている。
// list 2
var send = function (dest, msg) {
var relay = {dest: dest, msg: msg};
while (relay.dest.receive(relay.msg, relay));
return relay.msg;
};
var Node = function () {
var id = 0;
return function () {
this.id = id++;
this.dest = this;
this.receive = function (msg, relay) {
if (typeof this.count == "number") {
if (this.count == 0) return false;
this.count--;
}
relay.dest = this.dest;
relay.msg = msg;
return true;
};
};
}();
var n = 1000, m = 1000;
// 以下list 1と同じ
list 3では各ノードのメソッドreceiveおよび関数から見える変数で受け渡している。この変数をクロージャによりグローバルから隠蔽しようと、関数sendもノードのメソッドにしてしまった。
// list 3
var Node = function () {
var id = 0;
var relayDest, relayMsg;
return function () {
this.id = id++;
this.dest = this;
this.receive = function (msg) {
if (typeof this.count == "number") {
if (this.count == 0) return false;
this.count--;
}
relayDest = this.dest;
relayMsg = msg;
return true;
};
this.send = function (msg) {
relayDest = this;
relayMsg = msg;
while (relayDest.receive(relayMsg));
return relayMsg;
};
};
}();
var n = 1000, m = 1000;
var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
ring[i] = new Node();
ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;
var t = new Date();
var lastMsg = ring[0].send("read me in turn.");
t = new Date() - t;
alert("elapsed time:\n" + t + "[ms]\n\nmessage:\n" + lastMsg);
list 3のようにメソッドsendを全オブジェクトに付加しても呼ばれるのは一つだけでメモリ効率が悪いので、list 4ではプロトタイプで付加するようにした。
// list 4
var send;
var Node = function () {
var id = 0;
var relayDest, relayMsg;
send = function (msg) {
relayDest = this;
relayMsg = msg;
while (relayDest.receive(relayMsg));
return relayMsg;
}
return function () {
this.id = id++;
this.dest = this;
this.receive = function (msg) {
if (typeof this.count == "number") {
if (this.count == 0) return false;
this.count--;
}
relayDest = this.dest;
relayMsg = msg;
return true;
};
};
}();
Node.prototype.send = send;
var n = 1000, m = 1000;
// 以下list 3と同じ
list 5。list 1-4で用いたコメントアウト部のコードに替えて前半部のコードを用い、配列生成を回避した。変数n2が次のノード（新規オブジェクト）を参照しても、一つ前のノードにはさらに前のノードからの参照が残っており、オブジェクトが開放されることはなくリングが形成される。
// list 5
var n0 = new Node();
var n1 = n0;
for (var i = 1; i < n; i++) {
n2 = new Node();
n1.dest = n2;
n1 = n2;
}
n1.dest = n0;
n0.count = m;
/*
var ring = [];
ring[0] = new Node();
for (var i = 1; i < n; i++) {
ring[i] = new Node();
ring[i - 1].dest = ring[i];
}
ring[n - 1].dest = ring[0];
ring[0].count = m;
*/
(07/12 13:30 追記) 書き忘れていたlist 6。各ノードにメッセージを保持するプロパティmsgを持たせ、次ノードへのメッセージ伝達はノード自身が行い、メソッドsendは次順のみを管理する。もっとも素直に実装すればこの形になるかと思うが、list 3より若干遅い。（list 3を書き換えて再現したのでメソッド名と動作内容がかけ離れているが、差異がわかりやすいと思い、そのままにしておく）
// list 6
var Node = function () {
var id = 0;
var relayDest;
return function () {
this.id = id++;
this.dest = this;
this.msg = "";
this.receive = function () {
if (typeof this.count == "number") {
if (this.count == 0) return false;
this.count--;
}
relayDest = this.dest;
this.dest.msg = this.msg;
this.msg = "";
return true;
};
this.send = function (msg) {
relayDest = this;
relayDest.msg = msg;
while (relayDest.receive());
return relayDest.msg;
};
};
}();
var n = 1000, m = 1000;
// 以下list 3と同じ
アレゲは一日にしてならず -- アレゲ研究家
