Чи прийнятним є порівняльний показник секундоміра?

Хто-небудь коли-небудь використовує порівняльний секундомір, чи завжди слід використовувати інструмент ефективності? Чи є які-небудь хороші безкоштовні інструменти для Java? Які інструменти ви використовуєте?

Щоб пояснити мої занепокоєння, порівняльний показник секундоміра може зазнавати помилок через планування операційної системи. На даному запуску вашої програми ОС може запланувати інший процес (або кілька) в середині функції, яку ви синхронізуєте. У Java справа навіть трохи гірша, якщо ви намагаєтеся встановити час для потокової програми, оскільки планувальник JVM додає ще трохи більше випадковості в суміш.

Як ви вирішуєте питання планування операційної системи під час тестування?

Бенчмаркінг секундоміра - це нормально, за умови достатньої міри ітерацій, щоб мати сенс. Як правило, мені потрібен загальний час, який минув деяку кількість однозначних секунд. В іншому випадку ваші результати легко суттєво перекосяться за допомогою планування та інших переривань O / S у вашому процесі.

Для цього я використовую невеликий набір статичних методів, побудованих давно, на яких базуються System.currentTimeMillis() .

Для профілювання я використовував jProfiler протягом ряду років і вважав його дуже хорошим. Нещодавно я переглянув YourKit , що здається чудовим з Веб-сайту, але особисто я ним не користувався.

Щоб відповісти на питання про переривання планування, я вважаю, що повторювані прогони до досягнення послідовності / спостережуваних робіт на практиці викорінюють аномальні результати від планування процесу. Я також виявляю, що планування потоків не має практичного впливу для циклів від 5 до 30 секунд. Нарешті, після того, як ви пройдете декілька секунд, порогове планування має, на мій досвід, незначний вплив на результати - я виявляю, що 5-секундний пробіг постійно в середньому відповідає такому ж, як 5-хвилинний пробіг часу / ітерації.

Ви також можете розглянути можливість попереднього запуску тестованого коду приблизно 10 000 разів, щоб "розігріти" JIT, залежно від того, скільки разів ви очікуєте, що тестований код працюватиме з часом у реальному житті.

Це повністю діє, якщо ви вимірюєте досить великі проміжки часу. Я б виконав 20-30 запусків того, що ви збираєтеся протестувати, щоб загальний час, що минув, перевищив 1 секунду. Я помітив, що обчислення часу, засновані на System.currentTimeMillis (), як правило, складають 0 мс або ~ 30 мс; Я не думаю, що ви можете отримати щось більш точне, ніж це. Ви можете спробувати System.nanoTime (), якщо вам дійсно потрібно виміряти невеликий інтервал часу:

• документація: http://java.sun.com/javase/6/docs/api/java/lang/System.html#nanoTime ()
• ТАКО питання про вимірювання малих часових проміжків, оскільки System.nanoTime () теж має деякі проблеми: Як я можу виміряти час з мікросекундною точністю в Java?

Секундомір насправді є найкращим еталоном!

Справжній час відповіді кінцевого користувача - це час, який насправді має значення.

Не завжди можливо отримати цей час, використовуючи доступні інструменти, наприклад, більшість інструментів тестування не включають час, який потрібно браузеру для відображення сторінки, тому надскладна сторінка з погано написаним css покаже час секунди відповіді на тестування інструментів, але 5 секунд плюс час відгуку для користувача.

Ці інструменти чудово підходять для автоматизованого тестування та визначення проблем, але не випускайте з виду те, що ви дійсно хочете виміряти.

Профайлер надає більш детальну інформацію, яка може допомогти діагностувати та виправити проблеми з продуктивністю.

Що стосується фактичного вимірювання, час секундоміра - це те, що зауважують користувачі, тому, якщо ви хочете перевірити, чи все в межах допустимих меж, час секундоміра - це нормально.

Однак якщо ви хочете вирішити проблеми, профілі може бути дуже корисним.

Вам потрібно протестувати реалістичну кількість ітерацій, оскільки ви отримаєте різні відповіді залежно від того, як ви перевіряєте час. Якщо ви виконуєте операцію лише один раз, прийняти середнє значення багатьох ітерацій може бути оманливим. Якщо ви хочете знати час, який проходить після прогріву JVM, ви можете запустити багато (наприклад, 10 000) ітерацій, які не включені в таймінги.

Я також пропоную вам використовувати, System.nanoTime()оскільки це набагато точніше. Якщо час тесту становить близько 10 мікросекунд або менше, ви не хочете дзвонити надто часто, або це може змінити ваш результат. (наприклад, якщо я тестую протягом приблизно 5 секунд, і я хочу знати, коли це закінчиться, я отримую nanoTime кожні 1000 ітерацій, якщо я знаю, що ітерація дуже швидка)

Як ви вирішуєте питання планування операційної системи під час тестування?

Тест досить довго на системі, яка є репрезентативною для машини, якою ви будете користуватися. Якщо ваша ОС уповільнює роботу вашої програми, це має бути частиною результату.

Немає сенсу стверджувати, моя програма була б швидшою, якби тільки у мене не було ОС.

Якщо ви використовуєте Linux, ви можете використовувати такі інструменти, як numactl, chrtі tasksetконтролювати використання процесорів і планування.

Профілісти можуть заважати хронометражам, тому я б використовував комбінацію хронометражу секундоміра для виявлення загальних проблем з продуктивністю, а потім за допомогою профілювача визначав, де витрачається час. Повторіть процес за необхідності.

Врешті-решт, це, мабуть, друга найпопулярніша форма порівняльного тестування, відразу після "порівняльного тестування без перегляду" - де ми говоримо: "ця діяльність здається повільною, та здається швидкою".

Зазвичай для оптимізації найважливішим є те, що заважає взаємодії з користувачем - що найчастіше залежить від того, як часто ви виконуєте дію та що інше відбувається одночасно. Інші форми бенчмаркінгу часто просто допомагають їм у цьому.

Думаю, ключовим питанням є складність та тривалість операції.

Іноді я навіть використовую фізичні вимірювання секундоміра, щоб побачити, чи займає щось обчислення хвилин, годин, днів або навіть тижнів (я працюю з додатком, де тривалість роботи за порядком декількох днів не є нечуваною, навіть якщо секунди та хвилини найпоширеніші часові проміжки).

Однак автоматизація, яку забезпечують дзвінки до будь-якої годинникової системи на комп’ютері, як дзвінок Java Millis, про який йдеться у зв’язаній статті, явно перевершує ручну перевірку того, як довго щось працює.

Профайлери хороші, коли вони працюють, але у мене були проблеми із застосуванням їх до нашого додатку, що, як правило, передбачає динамічне формування коду, динамічне завантаження бібліотек DLL та роботу, виконану двома вбудованими, точно скомпільованими мовами сценаріїв моя заявка. Вони досить часто обмежуються припущенням однієї вихідної мови та іншими нереальними очікуваннями щодо складного програмного забезпечення.

Сьогодні я запустив програму, яка шукала та збирала інформацію з безлічі файлів dBase, на її запуск пішло трохи більше години . Я подивився код, зробив обґрунтовану здогадку про те, що таке вузьке місце, зробив незначне вдосконалення алгоритму та повторно запустив програму, цього разу вона завершилась за 2,5 хвилини .

Мені не потрібні були будь-які вишукані інструменти профілювання або набори тестів, щоб сказати мені, що нова версія стала значним покращенням. Якби мені потрібно було додатково оптимізувати час роботи, я, мабуть, зробив би ще складніший аналіз, але це не було необхідністю. Я вважаю, що такий різновид "секундоміра" є прийнятним рішенням у багатьох випадках, і вдавання до більш досконалих інструментів насправді було б більш трудомістким у цих випадках.

Я не думаю, що порівняльний показник секундоміра занадто жахливий, але якщо ви можете потрапити на машину Solaris або OS X, вам слід перевірити DTrace. Я використав його, щоб отримати чудову інформацію про час у своїх додатках.

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

Я роблю це постійно. Я б набагато скоріше використовував профайлер, але постачальник доменної мови, з якою я працюю, не надає такої.