Итак, я нашел 2 решения.
.section .text.startup
в файле, содержащем _start
.section .text.mustbefirst
(мое собственное имя раздела) в файле, содержащем _start
Во втором варианте я изменил скрипт компоновщика по умолчанию, чтобы убедиться, что мой символ секции был первым.
Если первое надежно (например, зависит от порядка аргументов или чего-то еще), то это нормально. Как в сторону; кто-нибудь знает? Если нет, то я бы порекомендовал новый символ раздела и модифицированный скрипт компоновщика.
OS X делает большое волшебство с общей памятью и страницами копии на записи, таким образом, возможности состоят в том, что не требуется так большого количества физической RAM для каждого приложения.
Можно проверить точно, как блоки памяти отображаются путем выполнения:
sudo vmmap <PID of the process>
Зависит от всей платформы (API), Вы используете. Объединение это с выделениями VM, сделанными низкоуровневой операцией в секунду.
Только стоит попытаться уменьшить выделение "кучи" (общее количество), а также резидентный размер кода. Удостоверяясь Ваши структуры данных выделяются эффективно и пытающийся скомпилировать с очень известным "-OS" флаг оптимизации (оптимизация размера). Нет очень, можно сделать о VM, который съело Какао. Я действительно не волновался бы об этом.
Это - ясно момент 'WTF' для разработчиков в целом. Вопрос обычно - почему мое тривиальное приложение израсходовало такую память.
Ответ до базовой платформы. Вы могли утверждать, что 6 МБ слишком много, но действительно, это - ничто.
Не редко видеть, что компьютеры идут с 2 ГБ памяти в эти дни. Запас IMAC составляет 4 ГБ. Смысл компьютерной индустрии должен израсходовать все ресурсы, которые имеет машина так, чтобы это продолжило развиваться.
Да необходимо избежать ineffecincies, где возможный (Не загружают 5 миллионов массивов точки при запуске, например). Но если Ваша бета не демонстрирует, что Вы уклонились, просто сохраняют его в списке todo's.
Я немного в затруднительном положении здесь, но я предполагаю, что это - потому что все библиотеки, которые добавляются, должны привести в порядок довольно мало установки и нет никакой потребности собрать "мусор", таким образом, они просто добираются для траты памяти; плюс, даже если бы вся память была автовыпущена, она ожидала бы до первого неактивного события, которое является после создания окна. Удалите ненужные библиотеки/платформы или вызовите мусор, собираются где-нибудь после загрузки окна от пера и видят, по какому количеству это спускается, если Вы так заинтересованы.
Я не обеспокоен этим. Часть памяти могла бы быть возвращена позже, и остальное - цена, которую Вы платите за мощную платформу.
Фактор, который напрямую не связан с какао, но в целом применим к каркасам, заключается в том, что накладные расходы не являются линейными. Обычно используется фиксированная и переменная «цена», с точки зрения накладных расходов, для использования каркаса.
Когда вы создаете простое пустое окно, фиксированные издержки разрушают, но когда вы создаете приложение с десятками окон, диалогов, элементов управления и всего, первоначальные фиксированные издержки становятся незначительными по сравнению с размером самого приложения.