Влияет ли длина имени метода на производительность? - PullRequest
12 голосов
/ 12 ноября 2011

Я старший разработчик, поэтому это кажется мне глупым вопросом.Мой ответ должен быть НЕТ или ЧТО?НЕТ !!!

Но я вчера был на собрании и объяснял некоторые результаты PMD.Когда мы подошли к проблеме «слишком длинного имени метода», я начал объяснять, и клиент сказал: ну, и помните, длинное имя метода влияет на производительность, программа работает медленнее.

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

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

Единственная идея, которая у меня есть, - это то, что с этим связана какая-то интроспекция или рефлексия, но, уверен, чтоЯ уверен, что длина имени метода не влияет на производительность.

Есть идеи или предложения по этому поводу?

Ответы [ 7 ]

18 голосов
/ 12 ноября 2011

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

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

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

4 голосов
/ 12 ноября 2011

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

1 голос
/ 14 ноября 2011

Время запуска будет положительно влиять на сокращение имен классов и членов. Для этого можно использовать сокращатель байт-кода .

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

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

1 голос
/ 13 ноября 2011

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

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

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

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

0 голосов
/ 13 января 2019

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

Это было протестировано на веб-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 мс быстрее, чем последний Ответ ...

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

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

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

С уважением

0 голосов
/ 20 сентября 2015

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

  1. время компиляции из байт-кода в двоичный код (с Java, .net, ..). Байт-код по-прежнему содержит имя файла, имя класса, имя пакета.
  2. если мы используем * .lib, * .dll, * .so, это может повлиять на производительность (в Android, например, когда вы используете собственный код)
  3. когда мы используем нативный код для вызова функции Java (в Java, Android)

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

0 голосов
/ 25 января 2012

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

...