Живее всех живых: Telegram набирает мощь несмотря на неполадки сервиса

(9)
Мало программируешь?

Вот пример, сегодняшний. Понадобилось мне в 1С на стороне клиента отсортировать массив либо по возрастанию, либо по убыванию, в котором 50000 объектов типа Структура с заполненными ключами. Сортировка должна быть по одному из этих ключей. Обычно все как делают - берут ТаблицуЗначений (сервер only) или СписокЗначений (доступен и на клиенте и на сервере). Чтобы отсортировать через ТЗ - надо перекачать массив на сервер, там создать объект, добавить поля, в цикле раскидать все ключи по полям, затем отсортировать и выгрузить обратно в массив. СписокЗначений, как класс полный отстой, т.к. позволяет сортировать только по значению, но никак не по одному из полей этого значения. Отметаем сразу.
Выбор пал на собственную реализацию алгоритма QuickSort (qsort), т.к. по известным причинам многого полезного в 1С отродясь нет и, похоже, не предвидеться. Реализовал пробный вариант. Первое во что я уперся это в рекурсию. Из-за нее отъелось непомерно много оперативной памяти и в какой-то момент клиент вышел за пределы и начал выполнять функции определенные в модуле формы, которые вообще ни откуда не вызываются, а были оставлены для отладки. Ладно думаю, буду реализовывать итеративный вариант сортировки. Переписал алгоритм с нуля. Запустил на тестовом массиве обычных случайных чисел, по диспетчеру задач видно, что потребление памяти нулевое, т.е. не растет. Процессор загружен на 16%. Через 1,5 минуты я увидел результат. Погуглил в интернете сколько времени занимает сортировка массива чисел на С++ быстрой сортировкой и выпал в осадок. Доли секунд. Пришло осознание, что надо оптимизировать код дальше. Первое что было сделано - любые вызовы собственных функций типа partition() и swap() были захардкожены в цикл. Скорость сортировки после этого возросла в 2 раза. Затем стало ясно что оптимизировать дальше особое нечего, т.к. невозможно оптимизироваться операции сложения или вычитания. Порывшись еще в интернете я решил попробовать свернуть цикл в одну строку. Скорость возросла с 40 секунд, до 10 секунд. Затем я решил свернуть в одну строку функцию целиком. И скорость сортировки стала 3,5 секунды.
Напомню это был тестовый массив. Дело дошло до реального массива, где нужен собственный компаратор, где уже не отделаешься инструкцией сравнения "arr[i]<=pivot". Кроме того нужен был контроль над сортировкой, по убыванию или по возрастанию. Когда я внес коррективы в алгоритм - скорость сортировки стала 70 секунд. Нормально, да? За универсальность я не был готов платить скоростью, поэтому реализовал 3 практически идентичные функции сортировки: а) классическую б) для сравнения по ключам объекта по убыванию в) для сравнения по ключам объекта по возрастанию. Затем я решил попробовать перегнать данные на сервер и отсортировать через ТЗ. И я получил все те же 3,5 секунды чистой сортировки без учета времени на переброс туда сюда. Но при этом на rphoste при заполнении ТЗ память отъедалась на пару гигабайт. А на клиенте при той же скорости она была стабильно той же самой что и до сортировки. Итак, убито несколько часов. Работодатель за это заплатит, все здорово, задача решена. И вы хотите сказать, что это нормально? Решать задачу, которая решается на С++ за 5 минут с такими танцами и бубном?