プログラマによる差が出る訳
プログラムとは、同じ処理を行うものでも、実現方法がいくつかある。
リアルの世界でどこかへ行く場合に、いくつかルートがあるのと同じだ。
「乗り換え案内」系のアプリは、社会人なら使った事があると思うが、あれで自分が今居る駅から目的地までのルートを検索すると、いくつか候補が出てくるのと同じだ。
到着時間が早いもの、運賃が安く済むもの、あるいは乗り換えが無くて楽なものとか。
どのルートを選ぶかは、その時の状況や個人の好みによるだろう。
プログラムの場合も、どのルートで処理を実現するかはプログラマの好みや経験によって大きく変わってくる。
経験が浅かったり、無能なプログラマだと、ものすごい遠回りなルートを選んだり、すごく運賃が高いルートを選んでしまったりする。
もっとも安くて早く目的地まで着くルートを選択するのは、昔と違って複雑なシステムが多くなった今は非常に難しい。
そもそも「乗り換え案内」のように、プログラムの処理のルートである「フロチャート」の候補をいくつか示してくれる便利なアプリとかは無いわけで。
「仕様」という目的地に向かって、どういうルートで進む（処理）するかは、すべてプログラマ自身が考えなくてはならない。
またどの命令（コマンド）を用いるかによっても大きく変わってくる。
Z80というパソコンには使わなくなったが、今でも多くの工業製品で使われているCPUで、例えば何かの値に1を足す処理をしようとすると、
ADD A,1
又は
INC A
という2通りの命令が使える。
前者はレジスタに任意の数値を加算する命令で、後者はレジスタの値を1だけ増やすという命令。
前者は1以外の数値も加算できるが、その代わり命令の記述に2バイト必要で、処理スピードもその分掛かる。
後者は1しか足せないが、命令の記述は1バイトで済み、処理スピードは加算命令としては最高速である。
マシン語でプログラムするなら、その時々によって最適な方を選択する事ができるが、現在開発に使われる言語はこのCPUが直接理解できる命令と1：1の、いわゆるアセンブラと言われるものでなく、開発言語独自の命令が使われ、「コンパイル」という処理をする事によって、開発言語のツールが独自命令をマシン語に直すのだ。
よって、「これは単に+1をしているだけだから、INC Aの方が速いしメモリも食わないからこっちでコンパイルしよう」とかやってくれないのだ。
足し算のソースは全てADD A、ｎ（ｎは任意の整数）の方でコンパイルされるのが普通だ。
つまり本当に最小限のメモリで超高速に動くプログラムを作ろうとしたら、「アセンブラ」で組まなければならないのだ。
なぜいまそうなってないかといえば、メモリ容量がZ80というCPUが主流だった頃よりも格段に増え、またCPUの処理スピードもめちゃくちゃ速くなったので、そこまでプログラムの大きさや速さに拘らなくても問題なくなってしまったからだ。
とはいえ、塵も積もればなんとやらで、プログラマにより同じようなアプリケーション・処理でもアホみたいに遅いとか、メモリ食いまくるとかってのも良く見る。
プログラムだけじゃなく、例えばネットゲームの大型アップデートなんかでも、数十分もしないで終わるゲームもあれば、1時間以上も永遠とアップデートに時間が掛かるのもある。
理由は明白で、実行ファイル（exeファイル）やデータファイルをそのまま送ってくるアホ運営と、きちんと圧縮を掛けて送ってくるまともな頭の運営の違い。
ス○エ○とか前者ですね。
何度か改善要望とか出しても、理解できないのか、しまいにはユーザーの回線やPCの性能がショボイせいだろｗｗｗってことになって低速回線・ボロPCお断りにしたほど。
コンピュータの性能が上がりすぎたが為に、こんなやつ等でもIT企業の技術者です（ﾄﾞﾔｧ）できるようになってしまったんですね。
悲しい事です･･･
リアルの世界でどこかへ行く場合に、いくつかルートがあるのと同じだ。
「乗り換え案内」系のアプリは、社会人なら使った事があると思うが、あれで自分が今居る駅から目的地までのルートを検索すると、いくつか候補が出てくるのと同じだ。
到着時間が早いもの、運賃が安く済むもの、あるいは乗り換えが無くて楽なものとか。
どのルートを選ぶかは、その時の状況や個人の好みによるだろう。
プログラムの場合も、どのルートで処理を実現するかはプログラマの好みや経験によって大きく変わってくる。
経験が浅かったり、無能なプログラマだと、ものすごい遠回りなルートを選んだり、すごく運賃が高いルートを選んでしまったりする。
もっとも安くて早く目的地まで着くルートを選択するのは、昔と違って複雑なシステムが多くなった今は非常に難しい。
そもそも「乗り換え案内」のように、プログラムの処理のルートである「フロチャート」の候補をいくつか示してくれる便利なアプリとかは無いわけで。
「仕様」という目的地に向かって、どういうルートで進む（処理）するかは、すべてプログラマ自身が考えなくてはならない。
またどの命令（コマンド）を用いるかによっても大きく変わってくる。
Z80というパソコンには使わなくなったが、今でも多くの工業製品で使われているCPUで、例えば何かの値に1を足す処理をしようとすると、
ADD A,1
又は
INC A
という2通りの命令が使える。
前者はレジスタに任意の数値を加算する命令で、後者はレジスタの値を1だけ増やすという命令。
前者は1以外の数値も加算できるが、その代わり命令の記述に2バイト必要で、処理スピードもその分掛かる。
後者は1しか足せないが、命令の記述は1バイトで済み、処理スピードは加算命令としては最高速である。
マシン語でプログラムするなら、その時々によって最適な方を選択する事ができるが、現在開発に使われる言語はこのCPUが直接理解できる命令と1：1の、いわゆるアセンブラと言われるものでなく、開発言語独自の命令が使われ、「コンパイル」という処理をする事によって、開発言語のツールが独自命令をマシン語に直すのだ。
よって、「これは単に+1をしているだけだから、INC Aの方が速いしメモリも食わないからこっちでコンパイルしよう」とかやってくれないのだ。
足し算のソースは全てADD A、ｎ（ｎは任意の整数）の方でコンパイルされるのが普通だ。
つまり本当に最小限のメモリで超高速に動くプログラムを作ろうとしたら、「アセンブラ」で組まなければならないのだ。
なぜいまそうなってないかといえば、メモリ容量がZ80というCPUが主流だった頃よりも格段に増え、またCPUの処理スピードもめちゃくちゃ速くなったので、そこまでプログラムの大きさや速さに拘らなくても問題なくなってしまったからだ。
とはいえ、塵も積もればなんとやらで、プログラマにより同じようなアプリケーション・処理でもアホみたいに遅いとか、メモリ食いまくるとかってのも良く見る。
プログラムだけじゃなく、例えばネットゲームの大型アップデートなんかでも、数十分もしないで終わるゲームもあれば、1時間以上も永遠とアップデートに時間が掛かるのもある。
理由は明白で、実行ファイル（exeファイル）やデータファイルをそのまま送ってくるアホ運営と、きちんと圧縮を掛けて送ってくるまともな頭の運営の違い。
ス○エ○とか前者ですね。
何度か改善要望とか出しても、理解できないのか、しまいにはユーザーの回線やPCの性能がショボイせいだろｗｗｗってことになって低速回線・ボロPCお断りにしたほど。
コンピュータの性能が上がりすぎたが為に、こんなやつ等でもIT企業の技術者です（ﾄﾞﾔｧ）できるようになってしまったんですね。
悲しい事です･･･
