HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2007
0901
tksstrmidが遅い12解決


tks

リンク

2007/9/1(Sat) 01:24:41|NO.10826

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

リンク

2007/9/1(Sat) 11:19:43|NO.10833

Dripです。

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

mes "Start" repeat 100000 font "MS ゴシック",16 loop mes "Completion."
他にも調べてみると「意外に重かった」という命令や関数がありそうですね。
とても興味深いです。



tks

リンク

2007/9/2(Sun) 22:07:22|NO.10858

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

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



Drip

リンク

2007/9/2(Sun) 23:25:09|NO.10859

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

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 "終りました。"



MIZUSHIKI

リンク

2007/9/3(Mon) 23:23:33|NO.10868

こんにちは。

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

#define _sample_ ;この行をコメントアウトしたらサンプルBのみ実行されます #ifdef _sample_ ;サンプルA : +=で文字列を足していく sdim a, 26*20000+1 mes "start A" repeat 20000 a += "abcdefghijklmnopqrstuvwxyz" loop mes "end A" #else ;サンプルB : 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でやってみたところ
すぐに処理が完了しました。
やはりどうやら前バージョンに比べ遅くなっているようですね。



tks

リンク

2007/9/14(Fri) 21:48:52|NO.11064

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

#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



f

リンク

2007/9/14(Fri) 22:01:39|NO.11065

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



tks

リンク

2007/9/14(Fri) 22:50:36|NO.11066

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

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



Kpan

リンク

2007/9/15(Sat) 00:18:21|NO.11067

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

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



tks

リンク

2007/9/15(Sat) 00:45:26|NO.11068

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

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



クリミア

リンク

2007/9/19(Wed) 08:19:48|NO.11118

メモ。

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

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

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

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

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


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



tks

リンク

2007/9/19(Wed) 15:24:14|NO.11119

> 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β9までならstrmidも0.1秒程度)

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



n

リンク

2007/10/2(Tue) 16:44:21|NO.11337

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



ONION software Copyright 1997-2023(c) All rights reserved.