OO言語における処理速度向上

RubyでもJavaでも留意しなければならない点はほぼ同じ。


手続き型言語と同じで一連のロジックの中で処理の重複をなくすのは当たり前である
ことがそこそこ意識されているのに対して、オブジェクトの生成回数を減らすことは
あまり意識されないことが多いように思える。


「変数を使い回すのは間違い」という書籍等による初心者に対する刷り込みが影響して
いるのだろう。使い回すことで何の影響もない一時利用のオブジェクトまで毎回生成
しているプログラムが非常に多い。


初心者がオブジェクトを使い回すと変なことになるのでそれはそれで正しいのだが、
中級者以上になったのならオブジェクトの使い回しによるロジックの処理速度の向上
を検討して当たり前だと思う。


追記→
変数やオブジェクトの使い回しによって保守性が低下するのは何の戦略(or 取決め)も
なしに変数やオブジェクトの使い回しを行うから。変数やオブジェクトを用途別
に使い回す等の戦略を定めておけば、保守性の低下は回避できます。
←追記


オブジェクトの生成はメモリ領域の確保に直結する。
オブジェクトを使い回すことはメモリ領域の確保処理をロジック上で減らす事に繋がる。


RubyJavaなどのOO言語では変数はポインタ(orリファレンス(参照))の入れ物にすぎない
ので、変数も積極的に再利用していくのが望ましい。
変数も初期化されるときにメモリ上に領域を確保していることを認識していない
プログラマは非常に多い。


メモリ領域の消費に関しては組込み系以外では用意されているメモリが潤沢なので
問題にならない場合が多い。問題はそこではなく、メモリ領域の確保時に掛かる
処理時間にある。



オブジェクト(インスタンス)の生成等のメモリの領域確保を伴う処理一つ一つが処理速度
に与える影響は僅かということは周知されているものの、一つ一つは僅かでも塵も積もれ
ば山になることは失念されていることが多い。


どうすれば作成したプログラムの処理速度を向上できるかを考えロジックを修正すること
プログラマにとって有益であると思う。


追記→
コンパイラによる最適化万能主義な馬鹿エンジニアもいるようですが、
コンパイラによる最適化は万能ではありません。
コンパイラによっては最適化されない、つまり、小手先のロジック最適化が有効な
ケースは多々あります。
勿論、コンパイラによる最適化が有効で小手先の最適化と同等の結果となり小手先の
最適化をする意味のないケースも多々あります、コンパイラによる最適化が有効な
ケースはコンパイラに任せるのが無難です。
コンパイラによって最適化されるケースと最適化されないケースを
知っておくことは必要だと思います。
→追記


プログラムのロジックが仕様(要件)を満たすのは最低ライン、より良く、より速く動く
ことを目指さなくてはいけない。


十中八九、汚いロジック(コード)の処理速度が遅いのは真。
処理速度を意識してプログラミングすればロジック(コード)は自然と綺麗になる。


ユーザのアクションに対する応答時間の短縮するにはユーザのアクションで呼び出す機能
の要件を削るか、削らずに処理速度の向上を行うかどちらかしかない、機能
の要件を削れることは外部要因の影響でほとんどない。


プログラムの処理速度が速いことはユーザのアクションに対する応答時間の短縮に直結
する。


UIや機能について考えることと、応答時間の短縮について考えることは同程度に重要。


どんなに見映えの良いUIを持ち、機能てんこもりでも、応答時間が許容範囲内(最低限、
イライラしない程度)でないシステムorサイトは誰も利用しない。
ユーザのアクションに対する応答時間は短ければ短いほどよい。応答時間が短いことは
それ自体、ユーザに対するウリになる、見栄えの良いUIに勝る場合も多い。


推敲中...。


[蛇足]
UIや機能について考えることと応答時間の短縮について考えることが同程度に重要で
あることを理解していないヘボエンジニアが日本の国内に非常に多い。
そんなヘボエンジニアが日々、ショボいシステムを量産している。


1・2年でプログラムを組めるつもりになっているビギナーがプログラミングを卒業して
システムの設計に携わるから日本国内の業務系システムが使えない出来の悪い玩具
(オモチャ)であふれかえっていく。


業務系システムではユーザのアクションに対する応答時間がユーザがイライラしない
範囲内(ユーザの許容範囲内)にあればいいので、処理速度はそれほど重要ではない。
殆どの場合、プログレスバーや時計アイコン等を表示してユーザを待たせればいいだけ
というスタンスで事足りる。


業務系システムではあっても処理速度を意識したプログラミングを開発初期から行える
ならそれにこしたことはない。
業務系システムの開発で処理速度向上のためのチューニングに時間を掛けるのは時間の
無駄でありクライアントからの要望があった場合を除いてすべきではないのは
言わずもがな。


#注)
#一から百まで書かないとわからない馬鹿向けにこの文章は書いているわけでは
#ありません。一から百まで書く義務はないし、時間の無駄なので一から百までは
#書いていません。
#
#(誰にむかって書いているかわからない文章(と書きながら特定の個人向けに書いた文章)
#を書き散らかしてみた箇所は取留めもなく纏まりもない唯の箇条書きになっていたので、
#とりあえず削除しました。→整理し直し、この文章に直接関係なさそうな箇所は分離
#しました。)
#
#一から百まで書かないとわからない馬鹿のために少し追記しています。
#