Производительность объекта параметра по сравнению с длинным списком параметров

Question

Я понимаю причину использования объекта параметра, когда дело касается методов обработки с длинными списками параметров. Но у меня есть ситуация, когда я хотел бы уменьшить объем памяти моего кода.

Вопрос у меня есть с точки зрения производительности. Сколько вы получите , перейдя в длинный список параметров?

Вариант использования заключается в том, что эти методы будут вызваны тысячами раз и каждый раз при вызове создается новый объект параметра. Я хочу действительно избежать создания всех этих объектов параметров.

Есть ли у меня «то же самое, что я могу есть, и съесть его», чтобы инкапсулировать параметры и использовать только хранилище стека?

К сожалению, в цепочке вызовов есть несколько методов, требующих всех этих параметров, и я не прочь сделать это изменение, поскольку эти методы не являются общедоступными. Просто хотел узнать о более эффективном решении.

Выполнение этого изменения повлияет на большую часть кода и займет много времени. Просто попробуйте проверить, стоит ли это сделать, прежде чем я поеду на этот маршрут.

Структура данных

Структура данных представляет собой объект графа. Объекты - это бизнес-данные, а связанные с ними края - это вызовы. Эти ребра связаны с данными параметров. Использование объектов параметров красиво, и мой код работает очень хорошо. Но меня не устраивает производительность и я хочу ее улучшить.

Я профилировал свой код, и эти объекты являются важной частью служебных данных памяти. Я сомневаюсь, что они в значительной степени способствуют загрузке процессора, но я определенно обеспокоен памятью.

Эта структура данных будет частью структуры, которая будет использоваться в высококонкурентной среде . Поэтому сокращение объема памяти вызывает у меня большую озабоченность.

Объект параметра имеет около 10 полей и некоторое поведение, связанное с ним. Я всегда могу инкапсулировать поведение в качестве альтернативы.

Answer 1

В зависимости от вашей ситуации. Основные проблемы с созданием объекта (в среде, не требующей ресурсов) - потребление памяти и время создания объекта.

В большинстве случаев время создания объекта является привязкой, если у вас нет многочисленных вложенных объектов. Для стоимости памяти подсчитайте количество примитивов и умножьте их на соответствующую стоимость памяти, затем добавьте восемь байтов для самого объекта. (И, конечно, сделайте это рекурсивно для любых содержащихся объектов.)

Для случая строк это примерно (40 + 2 * число символов) байтов. Это, очевидно, может быть изменено, но не резко. Для базовых массивов умножьте первоначальную стоимость на емкость, затем добавьте шестнадцать.

O-нотация создания в основном O-нотация вашего конструктора. Я уверен, что есть немного накладных расходов, но это ничего значительного. Для простого объекта параметра это, вероятно, несущественно.

Не толпите свое расписание, но наилучший подход, если эффективность важна, а ответ не очевиден, - это запустить тесты на обоих подходах.

Как я уже сказал, я не знаю вашей конкретной ситуации. Тем не менее, я решил аналогичные проблемы в прошлом с интеллектуальными отклонениями по шаблону Factory. Однако для этого потребуется еще один класс, и похоже, что это проблема для вас.

Answer 2

Существует несколько методов.

Если вас беспокоит нехватка памяти, вы можете создать фиксированный пул объектов параметров, а затем очистить их, когда они будут выпущены в пул. Таким образом вы выберете объект параметра из пула, установите значения (которые, я надеюсь, являются примитивами), а затем передайте их. После этого вы отбрасываете объект параметра в пул, который затем позволяет его повторно использовать.

Имейте в виду, что создание объектов в Java не имеет такой же производительности, как создание объектов на языках C++ или других языках (где объекты обычно очень дороги для создания). В некоторых случаях дополнительные объекты не стоят дорого, если что-либо вообще, из-за оптимизации JVM создание одного объекта часто объединяет память, необходимую для поддержки полудюжины или более «новых» вызовов.

Наконец, что касается использования хранилища стека, существует поддержка «хранения стека» объектов на Java, но чтобы он соответствовал языковому дизайну, это делается на завещании JVM и имеет ту же презентацию в код как куча хранимых объектов. Я не полностью разбираюсь в тех методах, которые вы использовали бы, чтобы получить объекты для возможного хранения стека, но я знаю, что вы не могли этого гарантировать.

Answer 3

Вопрос у меня есть с точки зрения производительности. Сколько вы получите , перейдя в длинный список параметров?

Существует множество причин для избежания длинных списков параметров, все из которых изложены в трактовке шаблона Builder в Effective Java, 2nd Ed.

Если ваш метод является частью внутреннего класса, который будет использоваться и поддерживается только вами, то, вероятно, нет никакого вреда при работе со многими параметрами. Но есть некоторые факты, которые следует иметь в виду. длинные списки параметров:

• сделать ваш код очень трудно читать
• могут увеличить вероятность труднодоступной отладки ошибок, особами. если список содержит несколько параметров одного и того же типа, которые могут быть непреднамеренно транспонированы
• заставляют вашу программу работать с трудностями
• может разрушить ваш API, если метод экспортируется клиентам, которые не смогут использовать этот метод без частых доступ к документации

Дело в том, что влияние оптимизаций (таких как списки параметров телескопирования) часто и обычно завышено. Да, JVM будет сбривать некоторые циклы с момента выполнения метода с использованием телескопического шаблона ... но учтите, что если этот метод содержит менее 10% общей обработки процессора всего вашего проекта (общий), то оптимизация бесполезна ,

«Сначала сделайте свою программу правильной, а затем ... и только тогда ...сделать это быстро, но только если профилирование указывает, что вам нужно.»

В самом деле, оптимизации относительно многих преимуществ, скажем, используя шаблон строитель на объекте обвязки для метода, который нуждается в большом параметры можно ожидать, приведет к потере времени и денег.

прецедент в том, что эти методы будут в конечном итоге называемых тысячи раз и каждый раз, когда вызов сделан, новый объект параметра Я хочу действительно избежать создания всех этих объектов параметров.

Для современных JVM время обработки, используемое для создания и сбора мусора, недолговечных легких предметов обычно превосходит объединение объектов.

Ваши проблемы действительны, но вам действительно нужно выполнить профилирование, чтобы узнать, есть ли причина в области памяти или производительности для оптимизации. Это особенно актуально, если стоимость оптимизации может стоить вам по-другому по дороге (ремонтопригодность, удобочитаемость).

Answer 4

После дальнейшего расследования это то, что я нашел.

Замены объектов параметров с помощью списка длинного параметра не собирается улучшить производительность, если следующий не является истинным

Объекты параметров не проводятся дольше, чем это необходимо в памяти

То, что я узнал от это упражнение помогло пролить свет на жизненный цикл объекта объектов параметров

Это помогло гарантировать, что объекты параметров действительно были короткими и не были разделены в других частях c ode излишне. Я должен был сделать немного рефакторинга, чтобы обеспечить это, и я оставил объекты параметров.