Какой-либо рекомендуемый Java профильное учебное руководство? [закрытый]
Добавьте метод map в список возможных решений с тем же регулярным выражением.
var array = [
'Asia <span class="hide">1234</span>',
'Ireland <span class="hide">65dhh</span>',
'US West<span class="hide">323-hth</span>',
'Asia Pacific <span class="hide">ap-ss-1</span>',
'US West <span class="hide">us-323223-1</span>'
];
var newArr = array.map(val => {
return val.match(/<span class="hide">(.*?)<\/span>/)[1];
});
console.log(newArr);4 ответа
Профилирование - это тема, имеющая более одной школы мысли.
Более популярная заключается в том, что вы действуете, получая измерения. То есть, вы пытаетесь увидеть, сколько времени занимает каждая функция и/или сколько раз она вызывается. Очевидно, что если функция занимает очень мало времени, то ее ускорение мало что даст. Но если она занимает много времени, то вам придется провести детективную работу, чтобы выяснить, какая часть функции отвечает за это время. Не ожидайте, что время выполнения функций суммируется с общим временем, потому что функции вызывают друг друга, и причина, по которой функция A может занять много времени, заключается в том, что она вызывает функцию B, которая также занимает много времени.
Этот подход может найти много проблем, но он зависит от того, насколько вы хороший детектив и способны ясно мыслить о различных видах времени, таких как время настенных часов против времени процессора и время работы самого себя против времени работы всего приложения. Например, может показаться, что приложение работает медленно, но время выполнения функций может быть почти нулевым. Это может быть вызвано тем, что программа связана с вводом/выводом. Если ввод-вывод - это то, что вы ожидаете, это может быть нормально, но программа может выполнять какой-то ввод-вывод, о котором вы не знаете, и тогда вам снова придется заняться детективной работой.
Общее ожидание от профилировщиков таково: если вы можете исправить достаточно вещей, чтобы получить 10% или 20% ускорения, это довольно хорошо, и я никогда не слышал историй о многократном использовании профилировщиков для получения ускорения намного большего, чем это.
Другой подход заключается не в измерении, а в захвате. Он основан на идее, что во время, когда программа работает дольше (в стенных часах), чем вам хотелось бы, вы хотите знать, что она делает, преимущественно, и один из способов узнать это - остановить ее и спросить, или сделать снимок ее состояния и проанализировать его, чтобы полностью понять, что она делает и почему она делает это в данный конкретный момент времени. Если вы сделаете это несколько раз и увидите что-то, что он пытается сделать в разные моменты времени, значит, эту деятельность можно плодотворно оптимизировать. Разница в том, что вы не спрашиваете сколько; вы спрашиваете что и почему. Вот еще одно объяснение. (Обратите внимание, что скорость создания такого снимка не имеет значения, потому что вы спрашиваете не о времени, а о том, что делает программа и почему.)
В случае Java, вот один низкотехнологичный, но очень эффективный способ сделать это, или вы можете использовать кнопку "пауза" в Eclipse. Другой способ - использовать определенный тип профилировщика, который делает выборку всего стека вызовов, по времени стенного времени (не процессора, если вы не хотите быть слепым к вводу/выводу), когда вы хотите, чтобы он делал выборку (например, не в ожидании пользовательского ввода), и подводит итоги на уровне строк кода, а не только на уровне функций, и в процентах от времени, а не в абсолютном времени. Чтобы получить процент времени, он должен сказать вам для каждой строки кода, которая появляется в любом образце, процент образцов, содержащих эту строку, потому что если бы вы могли заставить эту строку исчезнуть, вы бы сэкономили этот процент. (Вы должны игнорировать другие вещи, о которых он пытается вам рассказать, такие как графы вызовов, рекурсия и время саморазвития). Существует очень мало профилировщиков, отвечающих этой спецификации, одним из них является RotateRight/Zoom, но я не уверен, работает ли он с Java, и, возможно, есть другие.
В некоторых случаях может быть трудно получить образцы стека, когда вы хотите их получить, во время фактической медлительности. Тогда, поскольку вам нужны проценты, вы можете сделать в коде все, что облегчит получение примеров, не изменяя проценты. Один из способов - усилить код, обернув вокруг него временный цикл, скажем, из 100 итераций. Другой способ заключается в том, чтобы под отладчиком установить точку останова при изменении данных. Это приведет к тому, что код будет интерпретироваться в 10-100 раз медленнее, чем обычно. Еще один способ - использовать таймер с будильником, который будет срабатывать в период замедления, и использовать его для захвата образца.
Если использовать технику захвата многократно, чтобы найти и выполнить несколько оптимизаций, можно ожидать, что производительность будет близка к оптимальной. В случае большого программного обеспечения, где узкие места более многочисленны, это может означать значительные коэффициенты. Люди на Stack Overflow сообщали о коэффициентах от 7x до 60x. Вот подробный пример коэффициента 43x.
Техника захвата имеет проблемы в случаях, когда трудно выяснить, почему потоки ожидают именно тогда, когда они ожидают, например, когда ожидают завершения транзакции на другом процессоре. (У Measuring та же проблема.) В таких случаях я использую трудоемкий метод слияния журналов с временными метками.
Вы можете найти книгу «Производительность платформы Java» интересной. Опубликовано Sun Microsystems.
Как новичок в профилировании, вы должны начать с простого поиска методов, которые имеют длинный время выполнения и / или вызываются много раз во время типичных шаблонов использования / там, где возникают узкие места.
Я не уверен, как работает интеграция Eclipse с JProfiler, поскольку я в основном использую NetBeans . Однако в NetBeans есть представление «Снимок», которое показывает иерархию вызовов методов со средой выполнения, которая в сумме достигает 100%. Я ищу те части иерархии, которые занимают (относительно) большой% всего времени. Оттуда вы должны подумать о том, что делают эти методы и что может быть причиной их медленной работы.
Например: я заметил, что метод, который вызывается часто, в целом требует слишком много времени для завершения и является серьезным узким местом. Короче говоря, оказывается, что код проверял наличие элемента в коллекции с помощью метода .contains () , а коллекция была связным списком. Причина, по которой это является проблемой, состоит в том, что связанные списки имеют временную сложность O (n) для таких функций, как .contains () . Исправление в этом случае было довольно простым, поскольку я смог заменить связанный список на набор хешей, который выполняет .contains () намного быстрее, за время O (1).
JProfiler поставляется со справочным руководством. Я обнаружил, что это очень хорошо.