HSPTV!掲示板

HSPでセットできるタイマーの数に、仕様上の限界・実用上の限界はあるでしょうか？
たとえば、理論上は100個でも1000個でもセットできるが、ある程度増えてくると
重くなったり動作が不安定になる、など。

250〜500程度のタイマーを稼動させるアプリを作る予定ですが、数を減らした方がいいのでしょうか？
よろしくお願いします。

仕様上・実用上の限界は実装方法・実行環境に依存すると思いますが
少なければ少ない程、動作は軽く安定するような気がします。
(APIの割り込みタイマーですと処理競合の可能性もありますし…)

・極短い間隔のタイマーで各稼動時間になっているかチェック
・最も近い稼働時間でタイマーセット=>イベント駆動＆次に近い稼働時間でタイマーリセット
上記のような方法が可能ですとタイマー自体は1つで済みます。

ありがとうございます。
アドバイスに従いタイマーを1つにまとめてみたのですが、
起動して1分以内〜長くても３，４分で落ちるようになってしまいました。
落ちる際デバッグウィンドウが一瞬表示されるのですが、その後デバッグウィンドウごと
アプリのウィンドウも閉じてしまい、エラーメッセージが確認できません。
タイマーの間隔は1000（1秒）で、様々な処理を行った後その内容によって再描画を行います。
内部での処理や再描画に1秒以上かかるため、処理がどんどん積み重なっていって
落ちる、というようなことなのでしょうか？
ご指導お願いします。

現在の処理が完了する前に、タイマの割り込みによって再度処理が開始されて
(HSP内部の？)変数が想定外の値に上書きされているように思います。

上記の原因であれば、処理中はタイマを停止させる事で回避可能です。
(APIタイマであればoncmd 0で割り込み自体を停止する手もあります)
必要があれば処理前後でシステム時間を取得し、差分でタイマー時間を補正しましょう。

但し、これは 処理時間 ＜ タイマ間隔 での話ですし、
定期処理に1秒以上掛かるのはアプリとして実用的に厳しい気がします。
処理の最適化・マシン語化・マルチスレッド化等何らかの高速化を講じる事をお勧めします。

そちらに関して具体的なアドバイスをできる程のスキルは私にはありません。ごめんなさい。