Разбивка выделения при закачке на части

[zed]

Тут сложность не в процессе (хотя и он сложен), а в том, что при слиянии будут конфликты в коде и их нужно будет по месту решать, т.е. понадобятся навыки программирования на Delphi.

[Parasite]

при слиянии будут конфликты в коде и их нужно будет по месту решать

Возможно ли как-то максимально изолировать кусок кода с фичей, вынеся ее в отдельный файл с сорцем - а в основной ветке делать какой-нибудь инклуд одной строкой в нужном месте?
С программированием на дельфи у меня всё грустно.

[zed]

Естественно, я буду стараться сделать всё максимально изолированно и по началу, патчи даже скорее всего будут накладываться без конфликтов, но со временем, по мере изменения основного кода программы, что-нибудь наверняка придётся исправлять. Там может быть какая-нибудь мелочь, но всё же.

[vdemidov]

А ему и не надо знать порядок. Ему надо разбить область так (на столько частей), чтобы любой итератор мог по ней пройтись. Т.е. если его попросить разбить область на 3 части, это не значит что он обязан вернуть 3 полигона.

Потом, могут быть разные алгоритмы разбиения области. Вот тут заказчик просит разбить её по числу тайлов, а кому-то может захочется разбить на прямоугольники (как в примере в wiki) или ещё каким хитрым образом. А ты гвоздями прибиваешь это к итератору.

Это совсем другой алгоритм и уровень обработки. Я с самого начала предлагал просто разбивать полигон на куски, но Parasite забраковал. Сейчас речь именно про скачивание части тайлов конкретного полигона.

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

Она вообще никак не изменится по сравнению с текущей. Добавится два параметра в sls да и все.

[zed]

Это совсем другой алгоритм и уровень обработки.

Да и он будет возможен, если сейчас не прибивать гвоздями логику разбиения к итератору, как ты настаиваешь.

Она вообще никак не изменится по сравнению с текущей. Добавится два параметра в sls да и все.

Ухудшится гибкость и расширяемость.

[vdemidov]

Это совсем другой алгоритм и уровень обработки.

Да и он будет возможен, если сейчас не прибивать гвоздями логику разбиения к итератору, как ты настаиваешь.

Почему это невозможен? Очень даже возможен. Просто еще до создания итератора добавь разрезание полигона на куски.

Ухудшится гибкость и расширяемость.

Не ухудшится, а останется ровно такой как сейчас есть.

[Parasite]

Я с самого начала предлагал просто разбивать полигон на куски, но Parasite забраковал.

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

[zed]

Начал делать реализацию по своему варианту и оказалось, что при отдаче задания "по запросу", даже доп. поток не нужно создавать. Первый же рабочий поток, обратившийся за заданием, выполнит расчёт общего количества тайлов и определит свою стартовую позицию, все остальные в это время будут стоять на паузе. Когда первый всё высчитает и начнёт качать, по очереди продолжат вычисление своих стартовых позиций остальные рабочие потоки. И поскольку все вычисления происходят внутри TaskBilder-а, хоть и в разных потоках, лишних вычислений производиться не будет.

[zed]

Тестовая сборка: https://yadi.sk/d/vnwjUvffrnmcQ

- в гуе пока настроек нет, поэтому для теста разбивает на 4 части
- в sls пока не сохраняется информация о разбиении, так что при старте сохранённой сессии будет качать от начала и до конца

[zed]

Ну, вроде бы всё добил. Ночнушку пока не собирал, поэтому очередной тестовый билд: https://yadi.sk/d/D-eZHVR1roHLy

При открытии окна операций с выделенной областью, предлагаемое число, на которое может быть разбита область, выставляется исходя из настроек zmp (параметр MaxConnectToServerCount). Разбить область можно и на большее число (вплоть до 24 частей), но особого смысла это иметь не будет, по понятным причинам.

Подсчёт тайлов и разбиение происходит в одном потоке, все остальные ждут. Качать начинают одновременно, через 2 * O(N), т.е. по сравнению с запуском загрузки в один поток, тут время запуска увеличивается в 2 раза. При загрузке из sls будет считать всё заново, т.к. пока что не придумал, как сохранить и восстановить всю нужную информацию для горячего старта в sls.