過去の桐井戸端ＢＢＳ　（桐ver.８）

15864	一括処理の書き方による処理スピードについて	だるま	2002/05/01-11:58
一括処理の記述行を出っ来るだけ少なくする為（記述内容の見やすさ等まったくこだわらない）、 変数を思いっきり多用して、「ここまでするか！」くらい、細かな処理まで一般手続き化した一括処理と、 　同様の処理を記述行数にこだわらず、変数を利用しないでその都度直書きし、 同様の処理でも何回も記述した一括処理では、どちらの処理スピードが速いのでしょう？ 　突拍子もない質問ですが、宜しくお願い致します。<m(__)m> 　なぜこの様な質問をさせていただくかというと、 　主処理としているところから一般手続きにいったりきたりする回数等が処理スピードに影響がないか？ 　変数を多用する事が処理スピードに影響が出るのでは？ が気になっています。 　以上、宜しくお願い致します。<m(__)m>
15881	一括処理は書き方で処理速度が大幅に違います。	佐田　守弘	2002/05/02-00:22
記事番号15864へのコメント だるまさん 表題の通りで、一括処理は書き方次第で処理速度が大きく違う事があります。 ただし、それも状況次第ですから、一概には言えません。 ●処理速度低下の要因 桐がデータベースであるが故に、表データはディスク上に持ちます。 つまり、何よりも表データをディスクから読み書きする事が速度低下の最大要因です。 そして、それ以外は無視できる場合もあります。 なお、表のファイルサイズが小さければ、桐が使うキャッシュに収まってしまいます。 キャッシュに収まるかどうかは、表サイズが5〜6MB程度が分かれ目との話を聞いた事があります。 ●処理速度を下げる一括処理の書き方 (悪い例) 　置換 [消費税]=[売上高]*0.05 　置換 [請求額]=[売上高]+[消費税 (良い例) 　置換 [消費税]=[売上高]*0.05,[請求額]=[売上高]+[消費税 悪い例は、表を２回サーチしています。 良い例は１回に１レコードの複数項目を同時に置換していますから、表のサーチは１回で済みます。 (悪い例) 　繰り返し (.not #終端行) 　　行訂正 [消費税]=[売上高]*0.05 　　ジャンプ 行番号=+1 　繰り返し終了 (良い例) 　置換 [消費税]=[売上高]*0.05 繰り返しコマンドで１レコードずつの処理を繰り返すより、 表全体に対して一気に処理を行うコマンドの方が処理が早い様です。 ●御質問の件について 具体的にどの様な処理を行っているのかは、文面からは分かりませんので、 書かれている事だけで判断させて頂きます。 �@一括処理の大きさ 一括処理のファイルサイズが大きければ、それだけ読み込むのに時間が掛かります。 しかし読むのは１回だけですから、おそらく処理速度にそれ程影響しないでしょう。 もちろん、何10MBもの巨大な一括処理なら別ですが。 なお、一括処理ファイルも表整理を行って、不要な削除行をなくしておく事をお奨めします。 理由は上記の通りです。 �A手続きの多用 共通化できる処理を手続きに摺れば、一括処理ファイルは小さくなります。 つまり読み込み時間が少なくなります。 一方、順次処理を行う事に比べると、手続きを探すために多少の時間が掛かります。 しかし一括処理ファイル全体をメモリ上に読み込んでしまえば、 その時間は無視できる程度ではないかと思います。 �B変数の多用 変数に値を代入するには、それだけ時間が掛かります。 しかし、メモリ上での処理ですから、ほとんど影響ないのではないかと思います。 ●結論として おそらく質問されている事に関しては、どの様な方法でも余り処理速度に影響しないのではと思われます。 むしろ、冒頭に述べた様な例の他、案外と気がついていない所で、 大きな時間のロスをしている可能性があります。 やはり一番のポイントは処理のアルゴリズムではないかと思います。 アルゴリズム次第で、処理速度が大きく変わります。 これは、一概にどうとは言い様がありません。 ●かつての思い出から 以前、NIFTYのFAPPLI:桐たんすにて、桐の一括処理講座を開いた事があります。 課題として、フィボナッチの級数を作る一括処理を題材に掲げました。 私はそのときの応募者よりもそれなりに早い一括処理を作成しました。 しかし上には上がいるもので、ここにも登場されているいかすぱさんの作品は、 私のものよりも格段に早いものを作られました。 要するに、これはアルゴリズムの違いでした。 佐田守弘(KS-00119)
15897	Re:一括処理は書き方で処理速度が大幅に違います。	だるま	2002/05/02-19:53
記事番号15881へのコメント 　佐田先生、再三の突拍子のない質問に、いつも丁寧なご指導、誠に有り難う御座います。 　これも私にとって、桐の奥義になりそうです。 >キャッシュに収まるかどうかは、表サイズが5〜6MB程度が分かれ目との >話を聞いた事があります。 　上記もピクピク物です。（何のこっちゃ。(^^ゞ） >●結論として >おそらく質問されている事に関しては、どの様な方法でも余り処理速度に >影響しないのではと思われます。 　了解いたしました。m(__)m >アルゴリズム次第で、処理速度が大きく変わります。 　昔、「アルゴリズム」に思いっきりこだわっていた時が有りました。 　改めまして、今後とも宜しくお願い致します。<m(__)m>
15898	Re:一括処理の書き方による処理スピードについて	toshi-chan	2002/05/02-20:26
記事番号15864へのコメント こんばんは。佐田さんのしっかりしたコメントの後で少々恥ずかしいのですが、私の経験を紹介します。 ★桐５の時代に下記のような一括処理を書いたことがあります。併合を２１回行うわけです。 併合 "入力",両方,{[出庫年月日]照合，[製品名・規格]照合＆[製品名１],[数量]加算＆［数量１］} 併合 "入力",両方,{[出庫年月日]照合，[製品名・規格]照合＆[製品名２],[数量]加算＆［数量２］} 　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・ 併合 "入力",両方,{[出庫年月日]照合，[製品名・規格]照合＆[製品名２１],[数量]加算＆［数量２１］} ★これは結構メンテナンスが大変でした。その後繰り返しコマンドを使う方法を知り、下記のように書き換えました。 繰り返し　＆処理件数＝１，８５，４ 　　　代入　＆項目２＝＃項目属性（＆処理件数＋１２，１） 　　　代入　＆項目３＝＃項目属性（＆処理件数＋１４，１） 　　　編集表 "印刷用",更新=許可 　　　併合 "入力",両方,{[出庫年月日]照合，[製品名・規格]照合＆項目２,[数量]加算＆項目３} 　　　編集表”入力” 繰り返し終了 ★一括処理エディタ上では前者は２１行ありますが、後者は７行です。 しかし後者は繰り返すわけですから、 　　　　　７×２１＝１４７ となり１４７のコマンドを実行することになります。実際に一括処理を動かしてみると、 後者の方が時間はかかりましたね。数秒程度でしたが。その当時、私なりに考えた原因は、 　　�@実行するコマンド数が多い。 　　�A代入コマンドの実行に時間がかかる。 でした。 何かのお役にたてばと思い、コメントしました。
15900	多分併合の繰り返しによるものでしょう	佐田　守弘	2002/05/03-00:07
記事番号15898へのコメント toshi-chanさん 繰り返しコマンドを使って遅くなった理由は、 多分、併合コマンドを繰り返した事によるのではないかと思います。 多分代入コマンドは、無視し得る処理時間だと思います。これに対して併合は、 ２つの表を見比べる訳ですから、コマンドは１つであってもそれなりの時間が掛かります。 最初のプログラムは、併合コマンドの実行回数は３回ですが、後の方は、21回繰り返しています。 多分このために時間差が生じたのではないかと考えます。 とは言え、もし多少処理時間が遅くなったとしても、実用に堪える時間内であるなら、 メンテナンス性の良いプログラムの方が良いと言えるかも知れません。 佐田守弘(KS-00119)
15905	Re:参考になりました。	だるま	2002/05/03-17:15
記事番号15898へのコメント 　toshi-chanさん、ご返事が遅くなりまして、誠に申し訳御座いません。(^∧^) >★一括処理エディタ上では前者は２１行ありますが、後者は７行です。しかし後者は繰り >返すわけですから、 >　　　　　７×２１＝１４７ 　非常に参考になりました。有り難う御座いました。<m(__)m>

戻る