Щоразу, коли у вас є програма, яка має критичний шлях до продуктивності, ви повинні перейматися тим, як ви ставитесь до пам'яті. Більшість додатків для кінцевих клієнтів не підпадають під цю категорію, оскільки вони є основними подіями, і більшість подій випливає з взаємодії з користувачем, і у них не так багато (якщо взагалі є) обмеження продуктивності.
Однак багато програмного забезпечення повинно бути зосереджено на тому, як обробляється пам'ять, оскільки багато цього програмного забезпечення може масштабуватися для обробки більшої кількості клієнтів, більшої кількості транзакцій, більше джерел даних .... Після запуску Висуваючи обмеження, ви можете почати аналізувати, як пам'ять користувачів вашої програми та записувати власні схеми розподілу з урахуванням вашого програмного забезпечення, а не покладатися на повністю загальний розподільник пам'яті, який було написано для обробки будь-якого можливого випадку використання.
Щоб навести декілька прикладів ... в першій своїй компанії я працював над пакетом Historian, програмним забезпеченням, відповідальним за збір / зберігання / архівування даних управління процесами (подумайте про завод, атомну електростанцію чи нафтопереробний завод з 10-мільйонними датчиками, ми збережемо ці дані). Щоразу, коли ми аналізували будь-яке вузьке місце, яке заважало Historian обробляти більше даних, більшість часу проблема полягала в тому, як оброблялася пам'ять. Ми пройшли велику відстань, щоб переконатися, що malloc / free не називались, якщо вони абсолютно не потрібні.
На своїй нинішній роботі я працюю над цифровим рекордером відеоспостереження та пакетом аналізу. При 30 кадрів в секунду кожен канал отримує відео кадр кожні 33 мілісекунди. На обладнання, яке ми продаємо, ми можемо легко записати 100 каналів відео. Отже, це ще один випадок, щоб переконатися, що на критичному шляху (мережевий виклик => захоплення компонентів => програмне забезпечення для управління записом => компоненти зберігання => диск) немає динамічного розподілу пам'яті. У нас є спеціальний алокатор кадру, який містить відряди буферів фіксованого розміру і використовує LIFO для повторного використання раніше виділених буферів. Якщо вам потрібно 600 Кб пам’яті, можливо, ви отримаєте буфер 1024 Кб, який витрачає простір, але оскільки він підібраний спеціально для нашого використання, коли кожен розподіл дуже короткочасний, він спрацьовує дуже добре, оскільки буфер використовується,
У типі описаних мною програм (переміщення безлічі даних від А до Б та обробка великої кількості запитів клієнтів) перехід до купи та назад є основним джерелом вузьких місць роботи процесора. Зведення фрагментації купи до мінімуму є вторинною перевагою, однак, наскільки я можу сказати, більшість сучасних ОС вже реалізують купи з низькою фрагментацією (як мінімум, я знаю, що це робить Windows, і я би сподівався, що і інші). Особисто за 12+ років, працюючи в таких типах середовищ, я часто бачив проблеми використання процесора, пов’язані з купою, хоча жодного разу не бачив системи, яка насправді страждала від роздробленої купи.