20年前、コンパイラの最適化は（ほとんど）ありませんでした。そこで、次のようなハックを使い始めました。
swap()）を使用したり、マクロを使用したり、コードを直接記述したりしないでください。現在、複雑なコンパイラの最適化が行われています。配列のインデックスとポインタは同じです。（私が知っている、それは危険です）を使用する場合-O3、コンパイラはを除くすべての関数を削除しますmain()。
それで、古い本（プログラミング真珠、Cプログラミング言語）の小さなハックは今日役に立たないのですか？それらは単にコードを読みにくくしているだけですか？
プログラミングパールは、コードレベルではなく、アルゴリズムレベルでの最適化に関するものであるため、今日でも非常に関連性があります。
ただし、コードのマイクロ最適化は別の話であり、古いトリックの多くは冗長であるか、有害でさえあります。現在でもパフォーマンスが重要なコードに適用できる重要な手法がありますが、これらは将来のある時点で冗長/有害になる可能性もあります。CPUマイクロアーキテクチャとコンパイラテクノロジの進歩を常に最新の状態に保ち、適切なものだけを使用する必要があります（もちろん、絶対に必要な場合にのみ、時期尚早の最適化がすべての悪の根源です）。
「配列インデックスではなく、ポインタを使用してください。」
これはかつてないほど効率的です。ANSI-Cの古いドラフトでさえ、それらが同等であると指定しました。
3.3.2.1配列の添え字
添え字演算子[]の定義は、E1 [E2]が（*（E1 +（E2）））と同一であるということです。
「小さな関数（swap（）など）を使用したり、マクロを使用したり、コードを直接記述したりしないでください。」
これはかなり前から廃止されています。C99はinlineキーワードを導入しましたが、それ以前でも、コンパイラーはコードの一部を自由にインライン化できました。効率上の理由から、今日このような関数のようなマクロを作成することは意味がありません。
「それで、古い本（プログラミングパール、Cプログラミング言語）の小さなハックは今日は役に立たないのですか？それらはコードをより読みにくくしているだけですか？」
ここに続くのは私の個人的な意見であり、世界のプログラマーコミュニティ間のコンセンサスではないことに注意してください。これらの2冊の本は役に立たないだけでなく、有害であると個人的に言います。さまざまな最適化のトリックのためではなく、主に恐ろしくて読めないコーディングスタイルと、明確に定義されていない動作への大きな依存のためです。どちらの本もバグやタイプミスでいっぱいなので、隣に正誤表がないと読むことすらできません。
基本的にはそうです。しかし、最適化の機会を逃したという特にばかげた例を見つけた場合は、それを開発者に報告する必要があります。
ただし、Braindeadソースコードは常にBraindeadマシンコードを生成します。多くの一般的なイディオムが認識されて「修正」されますが、ある程度、コンパイラはあなたが意図したことではなく、あなたが言うことを実行する必要があります（ルールはデバッガーを使用せずに変更されたことを知ることは不可能です）。
そして、少なくとも一部のアーキテクチャでは、新旧を問わず、役立つトリックがまだあります。
たとえば、0から100までカウントし、配列に対して何かを行うループがある場合、一部のコンパイラはカウンターを逆にして100からゼロに下げる場合があります（ゼロとの比較は別の定数との比較よりも安価であるため）。ループに副作用がある場合、彼らはそれを行うことができません。副作用が逆の順序で発生することを気にしない場合は、自分でカウンターを逆にすると、より良いコードを取得できます。
GCCが持つもう1つの便利なトリックは、またはである可能性が高い__builtin_expect(expr, bool)コンパイラーに指示できるため、それに応じてブランチを最適化できるというものです。同様に、何かが起こり得ないことをGCCに伝えることができるので、それが起こった場合を考慮する必要はありません。exprtruefalse__builtin_unreachable()
ただし、一般的に、コンパイラーは十分に優れているため、プログラムが実行時間の90％をその1つの小さな関数に費やさない限り、実際に気にする必要はありません。（たとえば、memcpy通常はアセンブラで記述されます）。
これらのハックは、何らかの理由で最適化をオンにすることが許可されていない場合でも役立ちます。コンパイラーは、特定のコードの意図的および意図的でない副作用について知らないため、コードを最適化できない場合もあります。
それは本当にあなたが持っている要件に依存します。私の経験では、コンパイラーがあなたの意図をよりよく理解できるようにするために、より良い方法で表現できることがまだあります。より良いコンパイル結果を得るために読みやすさを犠牲にすることは常にトレードオフです。