2012-01-04 71 views
1

基本上我很想知道你走多遠,以確保用戶獲得最佳應用程序。提高應用程序性能的微不足道的方法

  1. 哪一個更喜歡動態/靜態內存分配,當兩者都有可能時。
  2. 刮012 int和使用shortint8_t。它真的有幫助嗎?或者這會更令人頭疼?
  3. 動態分配「按比例」大量內存(由於缺乏所需實際內存信息)。然後將其重新分配給較小的內存(壓縮)並刪除前者。例如。我分配1000個單位的內存。然後經過計算,我確定只需要400個單位。所以我分配新的400個單位,複製400個項目,然後刪除1000個單位。在這個過程中,我最終分配了更多的內存,即1400個單元。那麼我真的應該努力分配新的400個單位,讓600個單位浪費? [主要問題]
  4. 有效使用union有助於降低內存使用量嗎?

我相信還有更重要的一點缺失。歡迎任何其他已知或土着方式來增加記憶力和時間表現。

+1

如果它們不重要,那麼它們並不重要,對吧? – 2012-01-04 05:14:51

+1

7:不;請閱讀一本好書,並開始寫一些有用的東西,並獲得代碼審查,而不是過早地擔心你在酒吧裏聽到的東西。 – 2012-01-04 05:14:58

+0

我不能說這是一個列表問題,還是7個問題之一。無論哪種方式,在這裏看起來都不太合適。 – Flimzy 2012-01-04 05:15:27

回答

1

2. Static. Don't allocate memory when you don't need to.

3. If the system is a 32-bit system, then the actual instructions to the processor will actually prefer uint32_t or int32_t...

5. If I need a generic data type that would need to be allocated several times in a loop, then a union can come in handy... to avoid allocating memory.

6. From my experience, allocating memory can be a slow process if it is done in a loop... You will see a performance increase if you allocate all the memory ahead of time, and then use it from a pool. When the system has go find huge blocks of memory, it can be a bottleneck.

7. In real-time situations with large chunks of memory... yes... otherwise... eh... not really

希望這有助於...如果按照這個風格,你會發現改進的性能。

9

7。我的擔憂是否真實?

不是。您提到的所有內容通常都是無用的微觀優化,尤其是對於現代編譯器。寫代碼是最可讀的,因爲代碼被讀取的次數比寫入次數多。

+2

+1。祝福智慧的話語。 – 2012-01-04 05:24:33

+0

最好的回答我從來沒有讀過,因爲我成爲了stackoverflow的成員... :) – Owen 2012-01-04 05:33:01

+0

謝謝你確認我的恐懼! – 2012-01-04 06:04:29

1

這可能會更適合Programmers.StackExchange.com。無論如何,我通常遵循unix的哲學,不要固定瓶頸,直到你看到一個。

至於你的主要問題。這將會使用更多的處理週期,而不僅僅是分配大塊的內存並完成它,所以從這個意義上講效率較低。無論如何,內存現在相當耗費,效率,可重用性和可讀性通常是我最關心的問題。

如果您有此擔憂,請將-O3傳遞給您的編譯器。