有了這個問題，我的目標是更好地理解PHP的內部工作原理。包括選擇性或全球？
假設你有一個50K庫。該庫加載了一堆你在這裏和那裏使用的方便的函數。同時假設這些功能需要/使用比如你網站的10％的頁面。但是你的主頁肯定需要它。現在
，問題是...你應該使用全局包含指向該庫 - 全線 - 讓所有的頁面（包括90％不需要庫）將得到它，或你是否應該有選擇地在你需要的頁面上添加包含引用？
回答這個問題之前，讓我指出「爲什麼」，我問這個問題......
當您包括參考，PHP也可以將其高速緩存。因此，我擔心的表現可能是一次交易，而不是每次。一旦這一次阻礙，隨後的負載可能不會像人們想象的那麼糟糕。這完全是因爲PHP部署的智能緩存機制 - 我沒有深入的瞭解，因此，這個問題...
由於頭版需要該庫，因此參數可能是爲什麼不保存該庫溫暖和新鮮在記憶中，並得到它的全面服務？
在回答這個問題時，請從緩存/性能的角度嚴格地處理這個問題，而不是從方便的角度出發，以避免討論轉向編程風格以及該做什麼和該做什麼。
謝謝
測量它，那麼你知道。
緩存的好處是先打後可能邊際，因爲操作系統會緩存它爲好，但只有保存I/O命中（當然，這不是什麼）。但是，您仍然會受到處理衝擊。如果您將50K的代碼包含在「Hello World」頁面中，即使您沒有執行任何代碼，您仍然會支付CPU和內存的代價來加載和解析該50K的源代碼。這部分處理很可能不會以任何方式緩存。
一般來說，CPU是非常便宜的今天，所以它可能不會是「值得保存」。但這就是爲什麼你需要真正衡量它，所以你可以決定自己。
我認爲你所指的緩存是從APC之類的操作碼緩存？所做的只是防止PHP每次都需要解釋源。對於每個包含，您仍然需要點擊或需要使用。一個範例是取消程序功能並使用通過__autoload()加載的類。這爲大型應用程序提供了一種簡單的按需使用策略。同意威爾說，如果你擔心，你應該測量一下。過早優化永遠不會有幫助。
我非常感謝您對性能的關注。
簡短的回答是，爲了獲得最佳性能，我可能有條件地包括只需要它的頁面文件。
PHP的操作碼緩存將保持既包括緩存表單文件，所以你不必擔心使用其他類型的緩存可能在保持高速緩存「暖」爲你。緩存將一直保留，直到存在內存限制（不是50K腳本的問題），源文件更新，手動清除緩存或服務器重新啓動。
這就是說，操作碼（PHP字節碼）緩存只是PHP解析過程的一部分。每次腳本運行時，都會處理字節碼，以構建在腳本中定義和可選使用的函數，類，對象和其他實例變量。這一切加起來。
在這種情況下，簡單的更改可以顯着提高性能。是綠色的，每個週期計數:)