アプリケーションの考慮すべき事の一つにパフォーマンスコストがあります。拘り過ぎると製造コストの悪化になることがあります。「文字列を処理する時はstring型よりstringBuilder型を使え」とよく言われます。StringBuilderを使うには New StringBuilder() が不可欠でインスタンスコストが発生するので、String型より早いとは一概に言えません。GCコストもかかるので、最適コストは見つけ難いです。「乗算より除算のほうがコスト高なので避けるように」とあったりします。が a = 10 / 2 を a = 10 * 0.5 に置換すると、ソースの可読性が悪化することもあります。 10/2 だと「二人で分ける」と読み取れますが、 10 * 0.5 だと意味不明になります。
シーケンス制御や遅延ロジック処理などのマシンサイクルを意識するアプリではコスト概念は重要になりますが、業務アプリでは可読性と保守性がコストより勝ります。ここを間違えると、保守工程で思わぬ工数やバグに見舞われたりします。
1万回LoopしてmSec単位のコスト差がでるのは誤差の範囲でコスト差はないと見ています。(Stringや日付型は要注意ですが)
スーパーでの食料品の買い物では 一円二円の差を意識します。 100円単位の買い物に対する1円ですので大きい。
車は 100万単位なので一円二円の差は気にもしないですね(する人がいたらごめんなさい
)比率でみれば, 1000000:1
DataBaseのアクセスは、自分の端末での平均は 8mSecから20msec 程度とばらつきが大きいです。 一方、データ加工のループなどの処理部分は 0.1から5μSecでした。
比率でみると 0.001sec : 0.000001で スーパーの買い物レベルの比なのでロジックのコスト考慮は必須です。しかしロジック中の * / + - ()の順、や代入処理などは100000回Loopさせないと計測できないくらい低コストです。10万回Loopして 10μSecだってりするので、比率は 0.001sec : 0.0000001/100000 => 100000000: 1 となり 家を作る時に一円二円を値切る話になったりします。コストの低減は重要な要素ですが、低減効果の高い箇所で、低減化作業自体の低減化も重要な要素です。
変な言い回になってますが、1mSecの節減の作業に1日費やすことの妥当性の検証も大事だと考えています。
(*)上記は業務開発の側面からの話です。 何日かけても1msecの改善する技量は必要だと認識してますのでご了承ください。