配列のサイズ、次元数が大きい程、個々の配列関連処理に時間が掛かる。

概要

例えば、単純に配列に数字を書き込むだけの処理でも、配列が大きく成れば成る程、１回当たりの処理時間が増える。 1次元配列より、2次元配列の方が配列サイズ増加に伴う回数当たり処理時間の増加の程度は激しく、幾何級数的に増加する。（注：配列が大きければ、其れ全体を処理するのに時間が掛かるのは当然だが、ここでは個々の式の処理に時間が掛る様になるという事を意味している。) 配列から要素をGetする場合もほぼ同じ結果なので、配列へのアクセスに時間が掛っているように見える。

ちなみに、UWSCでは回数当たり処理時間は、1次元配列より2次元配列の方で多少の増加は有るが、配列のサイズには関係なくほぼ処理時間は一定している。

本件は、UWSCで1秒以内に終わっていたワンクリック・オペがUWSCRに移行後　5～6秒掛かる様に成った事に端を発しています。色々調べた結果200～300回　ForでLoopするコードの中に180*6サイズの2次元配列を毎回10回位ずつアクセスしている事が主たる原因であることが判明しました。

という事で、改善策を模索する意味でも必要となる為、思い切ってベンチマーク用のスクリプトを書きました。当方の古くて遅いPCで走らせたベンチマークの結果も含めて、そのプログラム、及びマニュアル等々を送りますので、詳細については、そちらを参照下さい。

なお、一時的な解決策として、CSV又はTSVファイルを配列代わりに使えば、UWSCにほぼ匹敵するパフォーマンスが得られる事が判り、それ関連の関数も作りましたので送ります。疑似配列の宣言、SetClear,Get,Put,Addの機能を含みます。

BenchMark.txt BMTestOrg.txt BMTestCase.txt BMResultO.txt BMTestCaseP.txt BMResultP.txt ベンチマーク・マニュアル.txt Functions.txt

再現スクリプト

以下のファイルを送ります。.uwsは.txtに替えて送ります。

BenchMark.uws      メイン・プログラム　UWSC上でRun
BMTestOrg.uws      メイン・プログラムよって、ここにTestCaseを埋め込んだテスト・プログラムBMTest.uwsが生成される
BMTestCase.txt　 　1次配列、2次配列のサイズを変えて書き込み時間を計測するケース
BMResultO.txt　　　上記ケースのテスト結果のレポート

BMTestCaseP.txt　　TSVファイルによる疑似配列のテスト・ケース（上記配列テストと同じ処理をテスト)
BMResultP.txt      疑似配列のテスト結果。

ベンチマーク・マニュアル.txt

Functions.txt　　　TSVファイルを使った疑似配列用の関数

再現手順

上記ファイルをUWSCR.exe,　UWSC.exeと同じPathに置き、BenchMark.uwsの2行目にある　　PUBLIC Path = "C:\Users\Public\Documents" を、必要に応じて該当Pathに合わせて書き換えた後、BenchMark.uwsをＵＷＳＣ上で起動すると、　そちらのPCでBMTestCase.txtを使って実際に計測したレポートが作成されます。又、BMTestCaseP.txtを、BMTestCase.txtとReNameするか、又はBMTestCaseP.txtを開いて全体をクリップボードにコピーした後にBenchMark.uwsを起動すると、疑似配列のテスト結果が出ます。

BMTestCase.txtを自分で書いてテストする事も出来ますので、マニュアルを一読　下さい。　

バージョン

1.0.1

不具合発生環境

Windows 10

BMTestCaseP.txt BMTestCaseP.txtの　疑似２次元配列に関するスクリプトに問題が有りましたので、訂正したファイルを送ります。 PROCEDURE PM_Initialize()中の"<#TAB>"はBenchMark.uwsで使う場合はCHR(9)に替えるべきであった事と、

TestCase:のFPUT中((a-1) Mod 10)は((a-1) Mod 10) + 1)であるべきでした。その為、変な内容のファイルが出来上がっていました。なお、この変更による処理時間計測結果には殆ど変化は有りません。

ところで、今日、初めて「UWSCRの配列について」（2023年12月05日付け)という記事を見付けたのですが、UWSCに比べて、利便性向上の面で大分尽力されたのですね。私の使い方では、配列リテラルのようにダイナミックに配列をいじるような事はないのですが、他の変数に代入出来る事等は便利さを感じています。それなのに、今回ケチを付けるようなことを事を、問題にして申し訳ないです。本件はその利便性向上の為の内部構造の変化の結果なのではないかと察します。ソースコードに対する影響範囲も大きそうですし、取り敢えずは現行通りで,　回避方法としてTSVファイルのパフォーマンスを紹介しておくのも良いのではないでしょうか？なお、必要なら、Functions.txtにある、私が使っている疑似配列関数にエラー・チェックを入れるなど、もう少し一般的な使用に耐えるスクリプトに仕上げる事も、やぶさかではありません。

@DIYJii

配列の処理に関しては実装が明らかに悪く、それがパフォーマンスに影響しているものと推測されます改善予定自体は以前からあったものの改善方法については検討中であり、まあ時間があるときにやりましょう…ということで後回しになっていましたとはいえ本件で問題が表面化したこともあり配列の実装改善タスクの優先度を上げることにしましたこれはバージョン1.1.0を目標とします

回避方法としてTSVファイルのパフォーマンスを紹介しておくのも良いのではないでしょうか？

配列のパフォーマンスに問題を感じた方はおそらくこのissueにたどり着くでしょうから、ここで参照できる形になっていれば十分だと思います

僕自身がバグissueを上げる際は現象の回避手段や代替コードがあればそれも併記するようにしています Issue自体もドキュメンテーションとして機能しますから、それを参照することでトラブルシューティング的に利用できると後から同じ問題に直面した方にとっては便利になりますよね

成る程、Issueの利用方法として、そんな事も考えられますね。私も、今後も出来るだけ回避策も含めたレポートを心掛けて行きます。本件修正のプライオリティーを上げる計画、有難いです。

On Tue, Jul 9, 2024 at 11:43 PM Joey Takahashi @.***> wrote:

@DIYJii https://github.com/DIYJii

配列の処理に関しては実装が明らかに悪く、それがパフォーマンスに影響しているものと推測されます改善予定自体は以前からあったものの改善方法については検討中であり、まあ時間があるときにやりましょう…ということで後回しになっていましたとはいえ本件で問題が表面化したこともあり配列の実装改善タスクの優先度を上げることにしましたこれはバージョン1.1.0を目標とします

回避方法としてTSVファイルのパフォーマンスを紹介しておくのも良いのではないでしょうか？

配列のパフォーマンスに問題を感じた方はおそらくこのissueにたどり着くでしょうから、ここで参照できる形になっていれば十分だと思います

僕自身がバグissueを上げる際は現象の回避手段や代替コードがあればそれも併記するようにしています

Issue自体もドキュメンテーションとして機能しますから、それを参照することでトラブルシューティング的に利用できると後から同じ問題に直面した方にとっては便利になりますよね

— Reply to this email directly, view it on GitHub https://github.com/stuncloud/UWSCR/issues/187#issuecomment-2217919212, or unsubscribe https://github.com/notifications/unsubscribe-auth/BH6AXYS4SIY7NWL536RTVU3ZLPZJNAVCNFSM6AAAAABKMUHSF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJXHEYTSMRRGI . You are receiving this because you were mentioned.Message ID: @.***>

stuncloud / UWSCR