Как линейное время превращается в Windows в O(n²)

[Logger]

Не смог пропустить такую статью, решил перепостить.
Для Аксапты тоже актуально.
https://habr.com/ru/post/479498/

Странно почему такие баги никто не тестирует. Нелинейность времени обработки легко поймать автоматизированным тестом.

[axm2017]

А как вы поймаете?
Время работы автотестов, как правило ограничено +-.
Ждать что тест рухнет через n часов работы никто не будет.

[Logger]

Зачем часы ? Чтобы выявить нелинейность не надо ждать часы.

1. создаем заказ 10 строк.
2. постим инвоис
3. засекли время
4. создаем заказ 100 строк.
5. постим инвоис
6. засекли время
7. создаем заказ 300 строк.
8. постим инвоис
9. засекли время
...

Если на каком то из шагов время возрастает нелинейно, то тест можно прерывать, он провален. Постинг документа можно делать в отдельном потоке (пакет ?) если не завершился за разумное время то тоже тест провален. Постинг принудительно прерываем.

По опыту разноски накладной по закупке/заказу, время не резко скачет до часов. Сперва минут 10 на 500 строк выскочит. Тут уже станет видна нелинейность. К этим цифрам скачком не подберешься.

[axm2017]

Цитата:

Сообщение от Logger

9. засекли время
...

Если на каком то из шагов время возрастает нелинейно, то тест можно прерывать, он провален. Постинг документа можно делать в отдельном потоке (пакет ?) если не завершился за разумное время то тоже тест провален. Постинг принудительно прерываем..

Если честно это какие то эмперические опыты.
При каких то звездах ок при каких то нет.

[Logger]

Ну, вы просто не занимались раньше этим вопросом.
Критерий очень простой и численно формализуем.

Померяли время, поделили одно на другое, сравнили с критерием.
Вы видимо просто не сталкивались с такими задачами.

[belugin]

У Андрея Акиньшина есть статья про сложности автоматического performance тестирования.

[gl00mie]

Цитата:

Сообщение от belugin

У Андрея Акиньшина есть статья про сложности автоматического performance тестирования.

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

DevOps-а на вас нет Вот когда какая-то проблема с производительностью или нестабильным поведением кода начинает капать тебе на мозг 80% рабочего времени (и еще сколько-то - нерабочего), то сразу забываются бредни про теоретическую нерешаемость задачи в общем виде, и находится решение, оптимизации какие-то сами собой рождаются, алгоритмы со сложностью O(n²) выкидываются на помойку, несмотря на их простоту и кажущуюся элегантность...

Проблеме с квадратичной зависимостью времени разноски документа в Аксапте от числа строк ведь не один год, даже не один десяток лет, а воз и ныне там. Сложно, мол, автоматически тестировать производительность, ага... И кинуть клич по партнерам/клиентам, чтоб узнать типовое количество строк в заказе за покупку или журнале розничной реализации (RetailStatement) и тупо тесты свои блочные гонять на этих объемах, а не на 10-20 строках, - тоже сложно. Пусть производительность будет чужой попаболью