我知道這完全是一個胡說八道的問題，但是由于我對編程技能的文盲，我想到了這個問題。使用 Cats 和 scalaz 以便我們可以在 Scala 中進行類似于 Haskell/純函式式編程方式的編碼。但是為了實作這一點，我們需要在我們的專案中額外添加這些庫。最終，為了使用這些，我們需要用它們的物件和函式來包裝我們的代碼。這是添加額外代碼和依賴項的東西。我不知道這些是否會在記憶體中創建更大的物件。這些都讓我思考。所以我的問題是：如果我使用cats/scalaz，我會面臨更多記憶體消耗等性能問題嗎？或者如果我的應用程式需要性能，我應該避免這些嗎？
uj5u.com熱心網友回復：
cat 和 scalaz 會在應用程式上產生性能開銷嗎？
絕對地。
就像任何一行代碼都會增加性能開銷一樣。
所以，如果這是你關心的問題，那么不要撰寫任何代碼（好吧，如果我們從未嘗試過所有這些，實際上世界可能會更簡單）。
現在，迪克在外面回答。您應該問的正確問題是：“X 庫的開銷是否對我的軟體有害？” ; 請記住，這適用于任何庫，實際上適用于您撰寫的任何代碼，適用于您選擇的任何演算法等。
而且，為了回答這個問題，我們需要一些東西。
- 定義您正在撰寫的軟體必須具備的 SLA。沒有這些，您所做的任何性能問題/觀察都是毫無意義的。如果您不知道這對您和您的客戶是否有意義，那么更快/更慢并不重要。
- 獲得 SLA 后，您需要執行壓力測驗以驗證您當前的軟體版本是否滿足這些要求。因為，如果您當前的代碼足夠高性能，那么您應該擔心其他事情，例如可維護性、測驗、添加更多功能等。
PS：請記住，這些 SLA 不應是原始數字，而應以百分位數表示，同樣如此對于測驗的結果。 - 當您發現自己的 SLA 下降時，您需要進行適當的基準測驗和除錯，以確定專案的瓶頸。如您所見，必須在每一行代碼上關注性能，但這是很多通常不會產生任何相關輸出的作業。因此，我們不是評估所有事物的性能，而是首先找到瓶頸，即那些對您的軟體整體性能貢獻最大的小段代碼（請記住帕累托原則）。
請記住，在這一步中，我們必須是完整的，網路也很重要。（您會看到最后一個通常是最大的減速；因此，通常您寧愿搜索架構解決方案，例如 usingFibers而不是Threads而不是試圖優化小功能。此外，有時更簡單、更便宜的解決方案是更好的基礎設施）。 - 當您發現瓶頸時，您需要制定一些替代方案，實施這些替代方案，不僅要對它們進行基準測驗，還要進行統計假設檢驗，以驗證提議的更改是否值得。當然，還要驗證它們是否足以滿足 SLA。
因此，正如您所見，表演是一門藝術，也是一項繁重的作業。因此，除非您致力于完成所有這些作業，否則不要再擔心您無法正確衡量和優化的事情。相反，專注于提高代碼的可維護性。這實際上也有助于提高性能，因為當您發現需要更改某些內容時，您會感謝代碼盡可能干凈并且代碼的整個架構允許輕松更改。
而且，當我這么說的時候，相信我，使用像cat 、cats -effect、fs2等工具會在這方面有所幫助。此外，它們實際上在其核心上進行了相當優化，因此您應該適用于很多用例。
現在，最大的例外是，如果您知道您正在做的作業將非常受 CPU 和記憶體限制，那么是的，您幾乎可以確定所有這些抽象都是有害的。在這些情況下，您甚至可能希望遠離JVM ，而是使用像Rust這樣的語言撰寫相當低級的代碼，這將為您提供解決此類問題的適當工具，并且仍然比普通的舊C更安全。
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/412155.html
標籤：
上一篇：撰寫一個視窗函式Spark