2010-07-28 2 views
2

В настоящий момент я работаю в среде с высокой доступностью, поэтому производительность - это проблема для этой компании. Я узнал, что сегодня они используют Perl 5.10.0, который, согласно perl5101delta, имеет регрессию производительности в списках. Теперь, когда мы находимся на Debian, обновление не так просто, поэтому я ищу статистику, чтобы указать, сколько обновления для обновления будет для нас обновляться.Есть ли тесты на то, насколько плоха регрессия производительности в Perl 5.10.0 была?

+3

Я клянусь, но у меня есть смутное воспоминание о том, что проблема исправлена ​​в патче Debian. Возможно, вы захотите проверить документацию Debian, чтобы узнать, что было изменено с восходящего потока. – Quentin

+0

@David Dorward Debian предоставил исправление для проблемы «Неизвестная ошибка» (ошибка debian 488088, Perl RT # 49472) к их 5.10.0, но я не знаю, что такое резервное копирование исправления списка, и я не знаю см. любые признаки этого в списке изменений. – hobbs

ответ

7

Контрольные показатели других людей будут только показывать, какая разница для кода других людей.

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

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

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

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

Как только у вас есть это и полностью не связанный с конкретными версиями, которые вы хотите перенести с или из, вы сможете установить любую версию, которую вы хотите перенести, с помощью App :: perlbrew, установить модули, которые вам нужны, чтобы получить тесты с App :: cpanm, а затем «просто» запустить тестовый набор.

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

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

Добавлено: Чтобы решить конкретный вопрос, о Perl в «измеримое падение производительности в присвоении списка» регрессии, можно установить различные Перлз через perlbrew и сравнить их с:

use Benchmark qw/:all/; 
sub test_this { 
    my ($a,$b,@c) = @_; 
    1; 
} 
timethis(10_000_000, "test_this(1..10);"); 

ли, что для Perl 5.10 и Perl 5.10.1 или другие перлы и см.

Для моей машины 5.10.1 дает 540k/sec, тогда как 5.10.0 дает 498k/sec.

+0

Хотя вы правы в этом бенчмаркинге, наш собственный код будет решением, он также требует много работы по установке perl 5.10.1 в сложной среде (даже с perlbrew), которую я не могу оправдать, если я могу " t даже указать, насколько плохо проблема в очень грубой манере. – Mithaldu

+0

Обновлено, чтобы ответить на комментарий – mfontani

+0

Да, это именно то, что я искал. Благодарю. – Mithaldu