新着記事

ハードウェア関係というか、庭関係含め物理的に体を動かすことが多かったもので、
ソフトウェア関係が滞っていました。体を動かすといっても、もっぱら軽作業でした
が。肉体的な運動量としては、アイロンがけとか半田付けとかその程度なので、
体重は減らないなぁ。

それはさておき。
めざらさんに教えていただいた時間計測ルーチンを仕込んで、同一の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秒
ぐらいだったりと不安定。きっといろいろと裏で動いているからだと思う。

以上、報告でした。
もっと良いアルゴリズムが思いつければ、乗り換えたいところではあります。
あと、上記の謎が解ければ、今のアルゴリズムで高速化できるかもしれないし。