ハードウェア関係というか、庭関係含め物理的に体を動かすことが多かったもので、
ソフトウェア関係が滞っていました。体を動かすといっても、もっぱら軽作業でした
が。肉体的な運動量としては、アイロンがけとか半田付けとかその程度なので、
体重は減らないなぁ。
それはさておき。
めざらさんに教えていただいた時間計測ルーチンを仕込んで、同一のBASICのソース
をリナンバーしたときの、各バージョンの所要時間を計ってみました。
開始 めざ 0.20 0.20
番号 増分 ら版 &s無 &s有 0.21 0.22a 0.22b
1 1 15s 11s 10s 9s 10s
10 10 15s 11s 10s 11s 11s
990 10 15s 25s 11s 11s 10s 11s
1010 10 15s 16s 17s 17s 17s
1020 10 15s 19s 19s 18s 19s
1030 10 15s 38s 19s 18s 19s 19s
1040 10 15s 17s 18s 17s 18s
10000 10 16s 25s 10s 11s 11s 11s
0.21 0.22a 0.22b がそれぞれどんなものかは#5876参照。
一応、0.21 0.22a 0.22bのいずれも、全て&sありです。
あ、#5867で&sの有り無しが逆転している。
&sの前のセミコロンの有り無し、つまりコメントアウトして抑止していたか否か、
ということに引っ張られていました。
うむ、誤差程度に0.22aが速いかな。
あと、開始番号が1020と1030のときが、微妙に所要時間が長い。
オリジナルは1000から始まっているので、行番号の重なりの関係が悪さをしている
と考えたのだけど、そうであれば990始まりの時だって大差ないはずなわけで、
この辺は非常に謎。
あと、どうでもいいかもしれない参考情報をいくつか。
めざら版は&s無しの所要時間だけど、&sつけて画面表示を抑止したら、なんと
たった４秒で変換が終わった。速い。これで既知のバグがなければ、ずっとこれを
使うのだけどなぁ。
もうひとつ、#5876で書いた、#55だけを変更した旧0.21。
会社のWin10のマシンだと、同じ変換を実行しているのに、3秒ぐらいだったり7秒
ぐらいだったりと不安定。きっといろいろと裏で動いているからだと思う。
以上、報告でした。
もっと良いアルゴリズムが思いつければ、乗り換えたいところではあります。
あと、上記の謎が解ければ、今のアルゴリズムで高速化できるかもしれないし。
関連記事一覧ツリー （▼ を押すとツリー全体を一括表示します）
返信フォーム （この記事に返信する場合は下記フォームから投稿して下さい）
- 以下のフォームから自分の投稿記事を修正・削除することができます -