わさっきhb

大学(教育研究)とか ,親馬鹿とか,和歌山とか,とか,とか.

登録件数が増えるごとに,1秒あたりの登録件数が増加したのはなぜか

○○さん

takehikomです.ごくろうさん.考察のスライドを見ました.「登録件数が増えるごとに,1秒あたりの登録件数が増加した」のあとに,理由を書きたい気持ちも分かりますが,明記しなくていいと思います.
むしろ,1,000件の登録と10,000件の登録とで,1秒あたりの登録件数が同じ値になっていることから,その数を(「件/秒」とともに)書いてから,「で頭打ちになっており,これが本プログラムにおける速さの限界と考えられる」を添えておくのは,どうでしょうか.
以下は質問があったときに答えられるよう,理解しておいてください.
練習時にも伝えましたが,登録件数が増えれば,登録の速さ(1秒あたりの登録件数)は低下します.というのは,一般にインデックス構築の時間は,登録文書のサイズに比例よりも大きくなるからです.
2年生のときに,アルゴリズムとデータ構造の授業を受けたと思います.そこで間違いなく,平衡木(balanced tree)も取り上げられていたはずです.レコードを挿入する際,挿入箇所の決定にコストがかかることを,思い出してくれればと思います.
今回,そうならず,件数を増やしても低下しなかったのは,登録件数が10,000件でもまだまだ小さくて,挿入のコストは,1件目でも10,000件目でも,差がつかなかったためと推測できます.
となると,一括登録プログラムで時間を要するのは,インデックス構築のところではなく,内部で呼び出す各コマンドの実行時間となります.
コマンド実行には,ディスク(実行コマンドも,OS内のファイルです)の読み出しを伴いますが,1回目だけは素直に読み出して,2回目以降は,キャッシュ機構により,直接読み出すことなく,実行プログラムをキャッシュ(メインメモリなど)から取り出して実行している可能性があります.そう考えれば,登録文書が多いほど,実行時間全体に対する「1回目の読み出し」の時間の割合が小さくなり,したがって,登録の速さへの影響が少なくなるのだと思います.

なにこれ

卒研生の1人から,発表練習をした晩に来たメールへの返信です.
なのですが,発表会では活用されませんでした.というのも,ある先生より「登録時間には,クライアント・サーバ間の通信時間が大きなウエイトを占めているのではないか」と指摘され,本人は戸惑ってしまったからです.
システム動作の内部説明で入れていたURLが,誤解のもとでした.実際には一括登録プログラムは,データベースと同一のサーバ上で動かしており,計算機間の通信は,考えなくてもよかったのでした.

わんもあ

卒業論文発表会では,最初のセッションで各発表者を呼ぶ際,「さん付け」にしてみました*1
あとの先生方も,引きずられたのか,学生を「さん付け」で読んでいました.しかし不慣れだったようで,セッション後の休憩時間は「くん付け」だったり,発表会の中でもセッション後半は,「くん付け」になっていたりしました.