50719


お世話になっております。

都度更新される情報において、いつも以下のことで思い悩むことがあります。  
例えば、キャラクターがマップ上を歩き視界範囲に何があるかチェックするようなシーンです。歩くので座標がいつも変わります。視力はだいたいが固定です（メガネ、コンタクト、晴れた日、雨の日、霧の日があるかも知れません）。  
・毎度処理させるか  
・中間値（ここでは視力）を変数に保管しとき、これを元に処理を簡略させるか

ハードのスペックとか、プログラム言語の性質とかあるかも知れません。その知識や調べ方が分からなく、そこまでハードリソースに逼迫した環境でもありません。  
アプリを作成しているのでiPhone、Swift4になります。

一般的にはどちらを選択する方が多いのでしょうか？

ビルドして検証してみて「負荷がなければ毎度処理で良い」で判断するものなのでしょうか？  
他の処理でその変数を参照することがない、且つ、CPU負荷時間よりも一般的にメモリ参照時間がボトルネックになるならば、毎度処理が良いものなのでしょうか？  
ご教授頂けると幸いです。

何卒よろしくお願い致します。


CC BY-SA 4.0
2018-11-27T22:10:08.100
50691
2020-04-01T01:40:08.860
2020-04-01T01:40:08.860
3060
20142
question
swift ios swift4
毎度処理させるか変数に格納するかの見極め方について


そういうのを決めるのが「設計」といいます。あれこれのトレードオフを見繕って、こっちの選択肢だとこういうメリットデメリットがある、あっちの選択肢だとああいうメリットデメリットがある云々、だからこうしてみるか。ってことで。

常に状況が変わるといっても人間側がついてこれなきゃゲームにならないわけです。数秒間同じ、ってのはコンピュータから見ると超絶長い時間なわけで、その間は再計算しても結果が同じであるってことなら計算結果を
RAM に保存しておくことをお勧めします。再計算すると CPU がアクティブになる＝消費電力が増え電池の残量が早く減る、ってことですよね。 RAM
は使っても使わなくても消費電力は変わりません。

> CPU負荷時間よりも一般的にメモリ参照時間がボトルネックになるならば

CPU で計算する際には必ずメモリの読み込み・書き込みがあるわけですが？


CC BY-SA 4.0
2018-11-28T01:17:53.570
50695
2018-11-28T01:17:53.570
8589
50691
answer


# 短いお返事

ハードリソースに逼迫した環境でないなら、  
まずは簡単に作れる、きれいな書き方をしましょう。  
リソース(CPU負荷,メモリ,ネットワーク等)が実際に問題になったら、  
全体をプロファイラによって計測し、最適化を考えましょう。  
コードをきれいに書くことで、結果として最適化をすばやく効果的に行う事ができるでしょう。

# 考え方を含めたお返事

パレートの法則といわれる経験則があります。

これは、全体のたった1％〜25%程度のプログラムが、  
処理時間のうち7５〜99%の間働いているという現象です。  
同じように、全体のたった1〜25%程度のプログラムが、  
メモリのうち75〜99%を使用してしまうという現象もあります。

ここからわかることは、1つ1つのコードで、  
CPUのため、またはメモリのために良くなるような形で  
プログラムを書くことを思い悩んだとしても  
少なくともその3/4は、ほとんど無意味になってしまう……ということです。

また「早すぎる最適化」という言葉があります。  
これはコードに対する高速化を早すぎるタイミングで行うことで  
結果としてコードを複雑化させてしまい、より大きな視点で考えたとき  
逆の最適化(不最適化)になってしまう事を言います。

つまりプログラムを後で書き換えやすい単純な形で書かなかったことで  
本当に一番問題になるプログラム「1%のコード」が見つかった時に、  
そこを書き換えることがなかなかできなくなっていて、  
良い結果が得られないということです。

普段のコードではCPUやメモリのことを、どちらも気にせずに  
「とりあえず単純でわかりやすく、かつ作ってしまいやすい書き方」でやってしまうほうが、  
結果として最適化にもつながります。

結論として **簡単だと感じる書き方** にしてしまいましょう。そして測り、改善しましょう。


CC BY-SA 4.0
2018-11-28T11:46:18.600
50719
2018-11-28T11:46:18.600
30827
50691
answer