HSPTV!掲示板

ver3.1β10以降strmidが遅い。驚くほど遅い。

sdim a,100001
repeat 10000
a+="abcdefghij"
loop
mes "start"
repeat 100000
b=strmid(a,0,1)
;sdim b,64
;memcpy b,a,1,0,0
loop
mes b

今頃気づいた。書き直さねば。

Dripです。

　こんにちは。これは意外ですね。
私が知ってるところでも、font命令が案外重い。とかです。

mes "Start"
repeat 100000
font "ＭＳ ゴシック",16
loop
mes "Completion."

他にも調べてみると「意外に重かった」という命令や関数がありそうですね。
とても興味深いです。

> 他にも調べてみると「意外に重かった」という命令や関数がありそうですね。

note系が遅いのは有名ですが、strlenも遅いです。strmidやstrlenの場合
バッファサイズに比例する遅さなので、少ない文字数だけでテストをしていると、
実際にファイルの文字列処理を処理をしたらとんでもなく遅いなんてことが
ありそうです。

少し前に変数の領域自動確保が滅茶苦茶重いことに気付いてソースを書き直した経験があります。
「バッファサイズに比例して重くなる」の類は結構多いのかもしれませんね。

sdim data,33554432
data="A"
repeat 25
data+=data
loop
mes "33,554,432 バイトの文字列を確保しました。"
mes "開始ボタンを押すと、 data+=\"あ\" を100回繰り返す実験をします。"
mes "変数の領域自動確保が案外重いことがわかる実験です。"
button "開始",*go
stop

*go
mes "スタート！"
repeat 100:data+="あ":loop
mes "終りました。"

こんにちは。

変数の領域自動確保が遅いのは割とわかりやすいですけど、
文字列を += で足していくのも、変数の中身が大きくなってくるとかなり重くなるみたいですね。
最近知って驚きました。
+= の変わりに、pokeで足していくと速いみたいです。

#define _sample_	;この行をコメントアウトしたらサンプルＢのみ実行されます

#ifdef _sample_
;サンプルＡ ： +=で文字列を足していく

sdim a, 26*20000+1
mes "start A"
repeat 20000
	a += "abcdefghijklmnopqrstuvwxyz"
loop
mes "end A"

#else
;サンプルＢ ： poke命令で文字列を足していく

sdim b, 26*20000+1
b_len=0
mes "start B"
repeat 20000
	poke b, b_len, "abcdefghijklmnopqrstuvwxyz"
	b_len+=strsize		;変数bに書き込んだサイズ分を記憶
loop
mes "end B"

#endif

詳しくはHSP3ラウンジのこのページ
http://fs-cgi-basic01.freespace.jp/~hsp/ver3/hsp3.cgi?print+200601/06020038.txt
のNo.11あたりのぷまさんの解説を見てください。
私もこちらで知りました。

しかし、strmidが遅くなっているとは知りませんでした。
最初のtksさんのスクリプト、HSP3.1でやると遅いのですが、試しにHSP3.0でやってみたところ
すぐに処理が完了しました。
やはりどうやら前バージョンに比べ遅くなっているようですね。

メニューバーの反応が遅いときがあるのも気になる。

#uselib "user32.dll"
#func global CreateMenu "CreateMenu"
#func global AppendMenu "AppendMenuA" int,int,int,str
#func global SetMenu "SetMenu" int,int
#func global DrawMenuBar "DrawMenuBar" int

CreateMenu
hmenu=stat
AppendMenu hmenu,0,0,"test"
SetMenu hwnd,hmenu
DrawMenuBar hwnd
oncmd *test,0x111
stop

*test
dialog
stop

基本機能についてはともかく、API云々の話になるのなら素直にVC++あたり使えば良いんでね？
まー、俺の考え方の問題なので強制するつもりは無いが。

> 基本機能についてはともかく、API云々の話になるのなら素直にVC++あたり使えば良いんでね？

oncmdの反応速度が遅いのかと疑ってみたのですが、早いときは早かったりなので、
ひとりごとでぽつりと…。

>font命令が案外重い
ループ中に、同じファイルをpicload命令とかbload命令で読み込みまくる
のと同じですな。
font命令は内部で↓の関数を呼んで、『フォントファイル読み込み⇒
論理フォント作成』ってな処理になっているので。
http://yokohama.cool.ne.jp/chokuto/urawaza/api/CreateFont.html

>メニューバーの反応が遅い
これはoncmd命令でgosub〜returnしてないからかと思います。

>メニューバーの反応が遅い
これはoncmd命令でgosub〜returnしてないからかと思います。

なるほど。そんな違いがあったとは。つぶやいてみて正解でした。ありがとうございます。

メモ。

処理スピードのテストをするときに、
mes命令やtitle命令をそのまま残すと
その命令の処理スピードの方が大きくて
うまく検証結果が得られないことがあるので、
動作確認がうまくいったあと、実際の計測には
それらの命令をはずすといいと思います。

また、初心者の方は、
「あの命令がおそかった」という話を目にすると
ちょっとためらいをおぼえるかもしれませんが、
strmidはとてもわかりやすい便利な命令だと思うので、
心配せずに使って、
もし完成したあと、速くしたいとか改良したいと思ったとき、
peekというので代替できることがうまく納得いったら、
それに置き換えたらいいと思います。

note系の命令も、終了時にセーブしたり起動時にロードするなど、
ループ処理内に置かなければ、重さの問題はないと思いますし、
これも感覚的にとてもわかりやすい便利な命令だと思います。
（セーブデータファイル自体もとても見やすいし）

あと、命令自体とは別の考え方として、
扱うテキスト側を整形（一時的もしくは元ファイルを）
してから処理を開始するというも有効かもと思ったり。

おぼえはじめのころはこういうトピックは
あたまが混乱してくるかもしれませんが、
だんだんわかってくるとこういうトピックがとても役に立つことが
判ってきます。


付記・
当方、ver3.1で、標準命令だけでテストしたところ
strmid と peek で文字列取り出しの比較をしたら
strmid 10割とすると、
peek 6、7割くらいの処理速度でした。（合ってるかな多分）

> note系の命令も、終了時にセーブしたり起動時にロードするなど、
> ループ処理内に置かなければ、重さの問題はないと思いますし、

それをやるときに遅いという話でして…（notegetを100000回とか。
以前beta-BBSでも出た）

> strmid と peek で文字列取り出しの比較をしたら
> strmid 10割とすると、
> peek 6、7割くらいの処理速度でした。（合ってるかな多分）

バッファサイズに比例する遅さだと書いたわけですが、どのように
比較されたのでしょうか？

sdim a,100001

repeat 10000
a+="abcdefghij"
loop

mes "start"

start_time=((gettime(4)*60+gettime(5))*60+gettime(6))*1000+gettime(7)
repeat 100000
sdim b,64
poke b,0,peek(a,0)
;memcpy b,a,1,0,0
loop
total_time=((gettime(4)*60+gettime(5))*60+gettime(6))*1000+gettime(7)-start_time
if total_time<0 : total_time+=86400000
mes strf("%.3f",1.*total_time/1000)

start_time=((gettime(4)*60+gettime(5))*60+gettime(6))*1000+gettime(7)
repeat 100000
b=strmid(a,0,1)
loop
total_time=((gettime(4)*60+gettime(5))*60+gettime(6))*1000+gettime(7)-start_time
if total_time<0 : total_time+=86400000
mes strf("%.3f",1.*total_time/1000)

私の環境ですと、peek・pokeやmemcpyで0.1秒程度、strmidだと16秒以上かかります。
(ver3.1β９までならstrmidも0.1秒程度)

文字列処理のためにループを回すことはよくあることですから、初心者の方であろうと
なかろうと、状況による使い分けが必要になったということだと思います。

状況による使い分けとか　今更？　って感じなんだけどね。
お前ら初心者のためにメモリチェックだとか経験者のために省メモリだとかに悩まされてんだよ開発元は。
贅沢言うなら他の言語使えばいいだろーがどうせ使えるんだし。