OT​/0001 のバックアップソース(No.1) :: OSASK計画

• 差分^[1] を表示
• 現在との差分^[2] を表示
• OT/0001^[3] へ行く。

* 小さいこと・速いことをどれだけ重視するか
-[[OsaTech]]より
-(by K, 2004.09.05)

*** 1.サイズや速さをどう評価するか
-非常に単純です。機能を損なうことなくサイズが半分になれば機能密度は倍になるので、サイズが半分にできたらこのプログラムは倍の価値になったと解釈します。
-速さも同様です。機能やサイズを損なうことなく速度が2倍になれば、それだけCPUタイムを節約できているのですから、時間に対する機能密度が倍になります。だからこのプログラムは倍の価値になったと解釈します。
-これ以上速くしても（実用上の）意味がないとか、これ以上小さくしても（実用上の）意味がない、ということは大いにありえます。それでも、改良の余地があるなら改良するべきです。もちろん、今すぐに改良に着手する必要はありません。実用上の意味があるところを優先して、そのあとでも十分でしょう。
-大事なことは、たとえもはや実用上の意味がなくなるくらいの段階に達していても、速さが倍になればやはり価値は2倍になり、サイズが半分になれば価値が2倍になる、という価値観を持ちつづけることです。この気分を守るだけで（＝それ以外に何もしなくても）、かなりOSASK的なコードに自然に到達するでしょう。
-なお、プログラマも人間ですから、やりがいがないとあきます。やりがいを維持するためにも、高速化の際には80%-20%ルールを意識しましょう。これで少ない労力で効率よくスピードアップできます。
-ついでにここでサイズ最適化のためのルールを簡単に説明しておきます。80%-20%ルールによれば、コードの20%が実行時間の80%に影響しているわけで、つまりコードの80%は速度が落ちてもほとんど影響がないということです。だからそのような80%に対してはサイズ優先で最適化します。サイズ優先部分では、高速なアルゴリズムなんて不要です。単純な（いわゆる馬鹿にされているような）アルゴリズムが重宝します。

*** 2.人間本位な考えを捨てる
-

• OT/0001 のバックアップ一覧^[5]
• OT/0001 のバックアップソース(No. All)
  • 1: 2004-09-05 (日) 14:57:23
  • 2: 2004-09-05 (日) 18:49:43^[6]
  • 3: 2004-09-06 (月) 14:49:01^[7]
  • 4: 2009-11-17 (火) 12:06:24^[8]
  • 現: 2024-01-08 (月) 12:58:49^[9] k-tan^[10]