Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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

Ответ 4

Время запуска будет затронуто положительно, если имена классов и имена членов сократятся. С этой целью можно использовать сжатие байт-кода.

Например, yguard (LGPL) может сжать код. Это также позволяет деобфобывать трассировки стека для целей отладки.

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

Ответ 5

Я не могу понять, почему это может повлиять на производительность значительно, если вы не вытаскиваете имена методов из себя через отражение, а затем визуализируете их в пользовательском интерфейсе. Это, очевидно, не так. Поэтому я просто смущен. Вы уверены, что ваш клиент не путает имя метода с именем файла или он думает о случаях, когда некоторые действительно старые языки программирования не поддерживают супер длинные имена методов? В зависимости от того, сколько лет этот человек, их суждение, безусловно, абсурдно для компьютерного ученого. Если они смогут доказать свою точку зрения фактом, они могут также отправить его в ACM, Oracle/Sun или MIT, чтобы проверить их результаты.

Ответ 6

Я думаю, что длина имени функции влияет на производительность следующим образом:

• время компиляции из байт-кода в двоичный код (с помощью java,.net,..). Байт-код по-прежнему содержит имя файла, имя класса, имя пакета.
• если мы используем *.lib, *.dll, *.so это может повлиять на производительность (в андроиде, например, когда вы используете собственный код)
• когда мы используем собственный код для вызова функции java (в java, android)

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

Ответ 7

При работе с Asp.Net CORE 2 WebAPI длина любого свойства внутри ResponseObject → оказывает влияние <- на время ответа

Это было проверено на веб-API ASP.NET Core 2, который обрабатывает простой запрос GET.

Сначала я создал объект ResponseObject следующим образом:

public class CelestialObjectResponse
{
    public CelestialObject CelestialObject { get; set; }
    public CelestialObjectClassification CelestialObjectClassification { get; set; }
    public CelestialObjectMeta CelestialObjectMeta { get; set; }
    public CelestialObjectPosition CelestialObjectPosition { get; set; }
    public IQueryable<CelestialObjectMarket> CelestialObjectMarkets { get; set; }
    public IQueryable<CelestialObjectResponse> Children { get; set; }
}

Когда я позвонил своему API, чтобы получить мои данные примерно с 1000 записями о небесных телах (у каждого есть классификация, мета, позиция, рынки и т.д.), Что привело к запросу 6,8 МБ.

Как только я реорганизовал объект ResponseObject, чтобы его имена свойств были намного короче, например:

public class CelestialObjectResponse
{
    public CelestialObject CO { get; set; }
    public CelestialObjectClassification COCL { get; set; }
    public CelestialObjectMeta COME { get; set; }
    public CelestialObjectPosition COPO { get; set; }
    public IQueryable<CelestialObjectMarket> COMA { get; set; }
    public IQueryable<CelestialObjectResponse> Children { get; set; }
}

затем размер ResponseObject привел к пакету в 6,2 Мб, который был доставлен примерно на ~ 300 мс быстрее, чем последний Response...

В связи с этим я могу сделать вывод, что если вы работаете с Asp.Net Core Web Api, длина свойства ответа НЕ ВЛИЯЕТ на время загрузки ответа в Asp.net API. Имейте в виду, что я мог бы изменить многие другие свойства внутри классов CelestialObject, Classification, Meta, Position, Market, чтобы получить этот размер ответа еще меньше!

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

Я надеюсь, что эта маленькая информация помогает

С уважением