Включение вызовов для отладки (), в если isDebugEnabled (): хорошая политика?
Я не уверен, что такое «регенератор рабочего времени», так что, возможно, проблема в другом месте. Но я видел несколько вещей.
Во-первых, похоже, что вам не хватает открывающей скобки для вашего метода:
async makeRestCall() {
var api = await PrognApi(this.state.Name);
console.log(api);
}
Во-вторых, Name с правильной заглавной буквой «N»? Интересно, имеет ли ваш метод контекст this? Возможно, у него проблемы с доступом к вашему компоненту state. Вы можете попробовать изменить его на функцию стрелки:
makeRestCall = async () => {
var api = await PrognApi(this.state.Name);
console.log(api);
};
Я не чувствую, что у меня достаточно информации, чтобы решить эту проблему. Может быть, обновить ваш вопрос, чтобы показать весь компонент?
Удачи!
6 ответов
Необходимо использовать SLF4J и сделать log4j реализация. С SLF4J, можно устранить isDebugEnabled() в целом при помощи параметризованных сообщений.
Видят эти раздел о регистрирующейся производительности в slf4j FAQ
, следующие две строки приведут к тому же самому выводу. Однако вторая форма превзойдет первую форму по характеристикам фактором по крайней мере 30, в случае отключенного оператора входа.
logger.debug("The new entry is " + entry + ".");
logger.debug("The new entry is {}.", entry);
Это - хорошая политика для тех случаев, куда строка журнала, которую Вы создаете, на самом деле собирается влиять на производительность значительно. Это могло быть по двум причинам:
- Большая работа должна войти в создание строки (например, это получено, чтобы сделать поиски или создать очень большую строку из большого количества очень маленьких частей)
- , Это находится в цикле, который не делает большой другой работы (но называется очень часто), таким образом, пропорция из времени, проведенного, создавая даже простую строку журнала, выше
, Это не должна быть всеохватывающая норма, и я буду ожидать, что обе из этих ситуаций будут относительно редки.
, Конечно, то, что мы действительно хотим, должно быть в состоянии сказать, "Назовите метод отладки, передающий в аргументе, который не является самой строкой отладки, но является чем-то, что знает, как к сборка строка отладки, если и только если это необходимо". Это было бы ужасно в Java без кратких закрытий. (Даже на языке с закрытиями в форме лямбда-выражений, получая следующие переменные могло быть значительным в некоторых ситуациях, в зависимости от того, как язык обрабатывает получение.)
Я соглашаюсь с известной кавычкой Michael A. Jackson :
Первое Правило Оптимизации Программы: не делайте этого.
Второе Правило Оптимизации Программы †“Для экспертов только: еще не делайте этого.
я думаю, что в большинстве случаев не стоит делать кодовую базу более сложной, не будучи уверенным, что увеличение производительности будет noticable / значительный.
я знаю о повышении производительности, но я думаю, что это должна быть обязанность отдельного программиста решить, стоит ли для добавления тех дополнительных строк кода в особом случае. В большинстве случаев дополнительные строки просто добавляют сложность без любого noticable усиления на стороне производительности.
Я не могу найти ссылку онлайн (возможно, я считал ее в книге), но был пример некоторого вызова BIOS, который записал Строку в экран.
код писание строки на экран, проверенный, чтобы удостовериться, что Строка не собиралась уходить экрана и затем вызвала функцию для выписывания символа на экран.
функция, которая записала символ в экран, проверенный, чтобы удостовериться, что символ не будет списан экрана.
Удаление проверки кодирует от функции, которая записала, что символ на экран привел к крупному повышению скорости. Потому что печать каждого символа происходила очень часто. Они также предоставили метод, который сделал проверку на случаи, когда экранное положение не было проверено перед вызовом.
Так, если можно проверить на высоком уровне и избежать проверок на низком уровне, можно значительно ускорить вещи.
В случае Вы обеспечиваете, если код находится в цикле или если бы существует много регистрирующихся операторов тогда было бы ясное преимущество, так как Вы были бы:
- удаляют строковое создание (и связанный GC)
- сокращают количество того, если операторы (хотя hotspote очень вероятно оптимизирует их).
я сказал бы, что в целом Вы не должны добавлять ничего, что, как известно, является дорогостоящим, если существует легкая работа вокруг. Это ясно попадает в тот случай - добавление, если оператор не трудно сделать, это - боль, чтобы вставить позже, и это обеспечивает определенное улучшение скорости/памяти.
я думаю, что различие между этой и преждевременной оптимизацией - то, что это, как известно, является всегда дорогостоящим, таким образом, проблема сводится к действительно ли ей, кумулятивная стоимость, которую Вы хотите добавить к программе или нет? Стоимость является в значительной степени постоянной, и она известна при написании кода.
Я думаю, что это делает с тех пор для помещения isDebugEnabled () вызов перед записью сообщения журнала. Чем Вы легко может обновить Ваше сообщение журнала позже. Мы используем следующий код для создания сообщений журнала более гибкими.
if (LOGGER.isDebugEnabled()) {
String msg = "A Message {0} you can put {1} differet Objects in {2}"; //$NON-NLS-1$
Object[] args = new Object[] {file1.toString(),new Integer(23),anObject};
LOGGER.debug(MessageFormat.format(msg,args));
}
, Когда Вы не имели бы оператор при потере времени. Помните..., что Ваш проект становится больше, и Ваш журнал обменивается сообщениями также.
сообщения Журнала не должны замедлять Ваш код!
Если "модель" уже известна, просто регистрирование ее не является настолько дорогим. Но, если "модель" должна быть выбрана только для входа как ниже, простота может быть поставлена под угрозу.
LOGGER.debug("model[" + proxy.getModel() + "]");