|
Notes |
|
|
|
Поясню, в п.3 и п.4 САС подготавливает в RAM полный список тайлов, попадающих в полигон для последующей работы. И время такой подготовки зависит в основном от общего количества тайлов в ограничивающем прямоугольнике. И от количества точек в полигоне. Потому на подробных зумах и больших областях будет долго. На z24 можно и не дождаться или памяти не хватит. :)
Насколько я знаю, тайловый кэш при этом ещё не задействуется, подготовка чисто математическая операция, проверка каждого тайла в ограничивающем прямоугольнике на попадание в полигон. |
|
|
|
|
>Поясню, в п.3 и п.4 САС подготавливает в RAM полный список тайлов, попадающих в полигон для последующей работы. И время такой подготовки зависит в основном от общего количества тайлов в ограничивающем прямоугольнике. И от количества точек в полигоне. Потому на подробных зумах и больших областях будет долго. На z24 можно и не дождаться или памяти не хватит. :)
Неправильно понимаете. Список никакой не строится. Память не выделяется. Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. Знаю как переделать, но мне пока сильно лень. |
|
|
|
|
|
Да, насчёт памяти был не прав, память подвела, осознал. |
|
|
|
|
>Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом.
Нельзя ли в тот тупой подсчет встроить возможность нормальной отмены по кнопке, а не через зависон и перезапуск САСа? Пускай оно строит все что ему надо, и как умеет - но отмена есть отмена: надо прекратить строить (на любом этапе) и выйти наружу. |
|
|
|
|
>Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом.
PS: значит ли это, что и при простом тайловом кэше зависание будет иметь место? Если так, то надо подредактировать шапку. |
|
|
|
|
|
|
|
(0009077)
|
|
Parasite
|
29-09-2012 13:38
(edited on: 29-09-2012 13:43) |
|
При обычном тайловом кэше строки начинают бежать практически с момента старта задачи - никаких несколько-минутных ожиданий нет, и проверить сабж не удается.
То есть, какая-то зависимость времени подсчета тайлов в полигоне от типа хранилища - таки есть.
Может действительно какие-нибудь индексы в Беркли читает? Или просто открытие БОЛЬШОЙ базы занимает долгое время...
|
|
|
|
(0009086)
|
|
zed
|
|
30-09-2012 14:57
|
|
Parasite
>При обычном тайловом кэше строки начинают бежать практически с момента старта задачи
А вот и не правда! Этот глюк одинаково воспроизводится на любом типе кэша и это именно тормоз подсчёта тайлов сложного выделения (непрямоугольного), при большом количестве тайлов. Никаких индексов БД не считывает...
vdemidov
>Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. Знаю как переделать, но мне пока сильно лень.
Как именно? Через отдельный поток? |
|
|
|
|
[offtopic on]
>Как именно? Через отдельный поток?
Мне тоже интересно как. А то давно хочу предложить метод ухода от перебора всех тайлов через проверку более крупных тайлов на меньших зумах, но это много писанины и будут ли его делать неясно. А самому ... не до того.
Может это на форуме лучше обсуждать?
[offtopic off]
Если одинаковое выделение запускается за разное время для разных типов хранилища, то надо бы проверить что тормозит и вылетает, создание итератора (подсчёт количества тайлов в полигоне) или уже далее, "открытие БД" (не уверен что под этим подразумевается).
Приложите образец выделения, на котором есть существенная разница в времени запуска и проверять ... |
|
|
|
|
>>Просто выполняется подсчет количества тайлов попадающих в область. Но выполняется очень тупым образом. Знаю как переделать, но мне пока сильно лень.
> Как именно? Через отдельный поток?
Нет конечно. Чисто алгоритмически это количество тайлов в области просчитывается за логарифмическое время от площади области.
>Мне тоже интересно как. А то давно хочу предложить метод ухода от перебора всех тайлов через проверку более крупных тайлов на меньших зумах, но это много писанины и будут ли его делать неясно. А самому ... не до того.
Да. Что-то вроде этого. Оно у меня даже реализованное почти есть. Посмотри в отедльном репо юнит u_PoligonToTileIndexer.pas если интересно. |
|
|
|
(0009090)
|
|
zed
|
30-09-2012 19:55
(edited on: 30-09-2012 20:00) |
|
Даже супер-совершенный алгоритм будет отнимать какое-то время, т.е. всё-равно остаётся вероятность появление глюка с зависанием САСа. Т.е. кроме улучшения собственно алго, нужно ещё и саму логику работы качалки изменить и не заставлять её висеть, пока идут расчёты (завести отдельный пул потоков на это дело).
P.S. Я когда-то пытался использовать AsyncCalls - можно воспользоваться, дабы для каждой мелочёвки не заводить свой пул.
|
|
|
|
|
>А вот и не правда! Этот глюк одинаково воспроизводится на любом типе кэша и это именно тормоз подсчёта тайлов сложного выделения (непрямоугольного), при большом количестве тайлов.
Я могу записать видео, собссно. При моих объемах скачки и параллельном тикете об останавливании закачек - я этот процесс наблюдаю помногу, ежедневно, и знаю наизусть.
При тайловом кэше: выделение (допустим, весь мир на 15м зуме - это много миллионов тайлов)->открывается окошечко закачки (уже с цифрами)->ТУТ ЖЕ начинают бежать строки о наличии в кэше.
Беркли: выделение (допустим, весь мир на 15м зуме - это много миллионов тайлов)->открывается окошечко закачки (БЕЗ цифр)->стоИт только рамка от окошечка (винт в это время напряжно работает, и если вот тут стопорнуть - то и будет сабжевый зависон)->так оно стоит кучку минут, всякую фигню обо мне думает (вместо циферок статистики по тайлам пока что показываются тильды "~")->появляются все циферки и начинают бежать строки о наличии в кэше. Вот тут уже можно отменять.
Это наблюдается при БОЛЬШИХ кэшах в беркли - от десятка гигабайт и выше по нарастающей. При мелких кэшах беркли - всё практически мгновенно.
Кстати, то же самое (долгая инициализация) и просто при свежем старте саса, в прошлый раз закрытом где-то на глубоком зуме - и при старте он восстанавливает прошлый вид окна и соответственно сразу хочет открытия этого болшогт глубоко-зумного кэша. Тоже проходит какое-то время (заметно более долгое чем с тайловым кэшем) пока картинка появляется...
Могу разогнать FileMon и посмотреть, что же именно оно читает в это время. Скажи, если надо.
>Никаких индексов БД не считывает...
Значит хранилище типа Беркли доставляет дополнительных тормозов при инициализации себя уже после подсчета числа тайлов, и просто накладывается на процесс старта закачки по ходу дела.
При тайловом кэше подсчет того же выделения на том же зуме выполняется мгновенно, повторюсь. Там циферки TOTAL в окошке появляются сразу. И вообще, не вижу причин подсчитывать что-то несколько минут на весьма простом квадратном выделении всего мира на одном зуме - я в уме эти Х*Y быстрее посчитаю, даже с миллионами. :)
>Даже супер-совершенный алгоритм будет отнимать какое-то время, т.е. всё-равно остаётся вероятность появление глюка с зависанием САСа.
Глюк появляется не от внутренней работы саса, а от попытки прерывания пользователем. То есть, подозреваю, что алгоритм не отрабатывает прерывание и нормальный выход из себя любимого - и "теряется в астрале" буде прерван сасом. Если ничего не трогать - то всё работает как надо. Но программерам таки виднее. :) |
|
|
|
(0009094)
|
|
zed
|
|
01-10-2012 06:37
|
|
>Могу разогнать FileMon
Разгони. И ещё посмотри в окошке DebugInfo сколько там тратится времени на считывание тайлов из кэша. Смотреть желательно сразу же после длительного старта САСа. |
|
|
|
|
>И вообще, не вижу причин подсчитывать что-то несколько минут на весьма простом квадратном выделении всего мира на одном зуме
Ну это вопрос отдельный, я не вижу особого смысла ускорять подсчёт для лишь прямоугольных выделений, слишком частный случай, тем более что и так быстро (по вашим же словам, при файловом кэше). Хотя это и довольно просто: проверить полигон на ровно 5 точек, проверить тайловые координаты всех точек на попарное точное совпадение (тут будет аж 8 вариантов! 4 варианта в каком углу начинается полигон и 2 варианта обхода) - значит прямоугольник. Писать столько кода? А надо ли?
Тормоза с беркли появляются уже потом, после подсчёта, но до вывода текста в форму.
Так что да, зависание именно из-за каких-то операций с беркли. |
|
|
|
|
>я не вижу особого смысла ускорять подсчёт для лишь прямоугольных выделений, слишком частный случай
>...
>Писать столько кода? А надо ли?
Ускорять подсчет никто и не просит - просят исключить зависон САСа при нажатии на "ОТМЕНИТЬ", когда один случайный тычок может поставить раком кучку идущих параллельно закачек в том же САСе. Я даже не против что оно по несколько минут думает перед началом скачки - и пусть бы ее, это весьма малая кровь за юзание базовода...лишь бы не висло! Оно ж при зависании еще и соседний кэш бьет, если рядом идет скачка в беркли в том же сасе. :(
Да, и на тайловом кэше всё считается практически моментально НА ТОМ ЖЕ ВЫДЕЛЕНИИ ТОГО ЖЕ ЗУМА ТОЙ ЖЕ КАРТЫ (они у меня, собссно, в отдельных файлах - так что за идентичность выделений ручаюсь). Может ведь, когда захочет... :) Тормоза идут откуда угодно еще, но не из подсчета тайлов в полигоне.
PS: сегодня будем потестировать с ФайлМоном - чего же оно там тормозит при начале скачки... |
|
|
|
|
|
Проверишь в завтрашней ночнушке. Поправил пару мелочей, которые могли влиять. |
|
|
|
(0009134)
|
|
Parasite
|
03-10-2012 10:19
(edited on: 03-10-2012 10:24) |
|
>Проверишь в завтрашней ночнушке. Поправил пару мелочей, которые могли влиять.
Хорошо.
Пока что - результаты вчерашнего ковыряния с файлмоном:
Карта - Яндекс.Гибрид штатный, ЗМП в составе саса
Полигон выделения - файл yahyb_RF.hlg отсюда: http://parasite.kicks-ass.org/vBulletin/showthread.php?t=106
Зум: 14й.
Винда: 2003Serv, на ХП - то же самое.
FS: NTFS
Отркываем полигон, пытаемся грузиться в кэш Беркли штатным образом. некоторый кэш этого зума на диске уже присутствует (прокачано примерно 50% от полигона).
Лог файловых операций с начала нажатия на кнопку СКАЧАТЬ:
-----------
8:54:28,6309297 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\SASPlanet.exe SUCCESS CreationTime: 05.09.2012 19:31:50, LastAccessTime: 18.09.2012 21:18:43, LastWriteTime: 04.09.2012 17:40:16, ChangeTime: 03.10.2012 8:40:45, AllocationSize: 4 866 048, EndOfFile: 4 864 000, FileAttributes: A
8:58:08,4739651 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A
8:58:08,4740076 SASPlanet.exe 2776 IRP_MJ_READ I:\$Directory SUCCESS Offset: 0, Length: 4 096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
8:58:08,5135749 SASPlanet.exe 2776 IRP_MJ_FLUSH_BUFFERS I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS
8:58:08,5161108 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS
8:58:08,5163968 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS
8:58:08,5170011 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS CreationTime: 29.09.2012 4:16:42, LastAccessTime: 29.09.2012 4:16:42, LastWriteTime: 03.10.2012 0:49:56, ChangeTime: 03.10.2012 0:49:56, AllocationSize: 76 410 880, EndOfFile: 76 409 856, FileAttributes: A
8:58:08,5172990 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
8:58:08,5176189 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
8:58:08,5178838 SASPlanet.exe 2776 IRP_MJ_FLUSH_BUFFERS I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS
8:58:08,5187117 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS
8:58:08,5189718 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\4\3\17.12.sdb SUCCESS
8:58:08,5192970 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A
8:58:08,5196242 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A
8:58:08,5199284 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A
8:58:08,5202163 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
8:58:08,5204961 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 0, Length: 512
8:58:08,5206229 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 0, Length: 4 096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
8:58:08,5296399 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS
8:58:08,5299620 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A
8:58:08,5302501 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Opened
8:58:08,5305253 SASPlanet.exe 2776 IRP_MJ_QUERY_VOLUME_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryInformationVolume, VolumeCreationTime: 05.04.2012 19:10:21, VolumeSerialNumber: E817-A748, SupportsObjects: True, VolumeLabel: USBo
8:58:08,5307832 SASPlanet.exe 2776 IRP_MJ_QUERY_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryAllInformationFile, CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, FileAttributes: A, AllocationSize: 33 554 432, EndOfFile: 33 551 360, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x2000000004d5d, EaSize: 0, Access: Generic Read, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Byte
8:58:08,5310503 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 890 112, Length: 1 024
8:58:08,5313466 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 0, Length: 1 024
8:58:08,5316155 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 855 296, Length: 1 024
8:58:08,5318604 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 1 024, Length: 1 024
8:58:08,5321107 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 761 088, Length: 1 024
8:58:08,5323508 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 2 048, Length: 1 024
8:58:08,5325939 SASPlanet.exe 2776 IRP_MJ_CLEANUP I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS
8:58:08,5329028 SASPlanet.exe 2776 FASTIO_NETWORK_QUERY_OPEN I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, AllocationSize: 33 554 432, EndOfFile: 33 551 360, FileAttributes: A
8:58:08,5331962 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: OpenIf, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: 0, OpenResult: Opened
8:58:08,5335071 SASPlanet.exe 2776 IRP_MJ_CREATE I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Desired Access: Generic Read/Write, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Random Access, Attributes: N, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
8:58:08,5337693 SASPlanet.exe 2776 IRP_MJ_QUERY_VOLUME_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryInformationVolume, VolumeCreationTime: 05.04.2012 19:10:21, VolumeSerialNumber: E817-A748, SupportsObjects: True, VolumeLabel: USBo
8:58:08,5340048 SASPlanet.exe 2776 IRP_MJ_QUERY_INFORMATION I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb BUFFER OVERFLOW Type: QueryAllInformationFile, CreationTime: 18.09.2012 23:02:26, LastAccessTime: 18.09.2012 23:02:26, LastWriteTime: 19.09.2012 8:30:30, ChangeTime: 19.09.2012 8:30:30, FileAttributes: A, AllocationSize: 33 554 432, EndOfFile: 33 551 360, NumberOfLinks: 1, DeletePending: False, Directory: False, IndexNumber: 0x2000000004d5d, EaSize: 0, Access: Generic Read/Write, Position: 0, Mode: Synchronous IO Non-Alert, AlignmentRequirement: Byte
8:58:08,5342803 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 11 173 888, Length: 1 024
8:58:08,5345862 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 3 072, Length: 1 024
8:58:08,5348322 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 683 264, Length: 1 024
8:58:08,5350910 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 30 538 752, Length: 1 024
8:58:08,5351060 SASPlanet.exe 2776 IRP_MJ_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 30 535 680, Length: 4 096, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
8:58:08,5480376 SASPlanet.exe 2776 FASTIO_WRITE I:\0.SAS_test\cache_db\yahyb\z14\4\2\18.8.sdb SUCCESS Offset: 12 684 288, Length: 1 024
8:58:08,5482855 SASPlanet.exe 2776 FASTIO_READ I:\0.SAS_test\cache_db\yahyb\z14\3\2\13.8.sdb SUCCESS Offset: 7 087 104, Length: 1 024
.......итд
-----------
Явно виден гап в 4 минуты (!) при старте операций - строки 1 и 2 в логе, в кое время САС просто стоит и ничего не делает. Загрузка камня при этом не меняется, так что явно ничего не считает настолько усиленно 4 минуты...
Скрин этого процесса (сабжевый, который и нельзя прерывать а то зависнет) - в шапке.
Старт того же самого, но в тайловый кэш - начинается, как и следовало ожидать, мгновенно.
|
|
|
|
|
|
Ну так как, зависание все еще есть? |
|
|
|
|
|
|
|
(0009229)
|
|
Parasite
|
07-10-2012 08:57
(edited on: 07-10-2012 08:58) |
|
Потестил.
Некоторое подвисание при отмене - осталось, но если подождать около минуты - то отрабатывает и выходит нормально. Жестко и навсегда САС уже не зависает, спасибо.
Нельзя ли как-то его вообще исключить (чтобы выход осуществлялся мгновенно - как при тайловом кэше)? Неизвестно, как этот минутный коматоз всей программы может повлиять на параллельно идущие закачки в Беркли - возможно, что там тайминги на операции или еще что-то...Ерроров вроде не вылазит, но мало ли.
PS: долгий старт перед началом первой закачки, тот что на скрине вверху - остался.
|
|
|
|
(0009233)
|
|
zed
|
|
07-10-2012 10:01
|
|
Я никак не могу понять, как у тебя тайловый кэш стартует мгновенно? Там же ж выполняется один и тот же код по подсчёту количества тайлов, причём вне зависимости от типа выделения. Хоть мега-сложное, хоть простое квадратное - идёт тупой перебор:
while Next(VTile) do begin
Inc(FTilesTotal);
end;
Вот он и тормозит. На любом типе кэша (да и кэш тут совершенно ни при чём, тебе ж FileMon всю правду показал!). |
|
|
|
(0009239)
|
|
Parasite
|
07-10-2012 10:37
(edited on: 07-10-2012 10:38) |
|
>Я никак не могу понять, как у тебя тайловый кэш стартует мгновенно?
А я откуда знаю? Я не в теме программинга сабжа - я лишь констатирую факт. Если бы меня тайловый кэш стартовал по 4 минуты - я был бы первым, кто про это написал бы. :)
Дело в том, что при юзании Беркли - сас 4 минуты просто стоИт и ничего не делает. Он НЕ считает тайлы по 4 минуты - он делает что-то еще, уникальное именно для беркли-кэша. И это не файловые операции.
PS: а число УЖЕ подсчитанных тайлов выводится сразу при загрузке выделения, ПЕРЕД стартом закачки (в том самом окне со вкладками "СКАЧАТЬ\СФОРМИРОВАТЬ\СКЛЕИТЬ...". Там все уже подсчитано, и оно выводится моментально для обоих типов кэша. При нажатии СКАЧАТЬ - тайловый кэш стартует моментально, а беркли - >4мин, см.лог файлмона выше).
|
|
|
|
(0009242)
|
|
zed
|
|
07-10-2012 10:48
|
|
Скажу так: описанная тобой ситуация, чтобы тормозил только Беркли - не воспроизводится. У меня тормозит одинаково на любом кэше:
1. Распаковываем чистую ночнушку. Сегодняшнюю.
2. Ничё не трогаем, находимся на z1, в меню Операции - Операции с выделенной областью, выбираем "По размеру экрана" -> Скачать -> ставим z19
3. Безнадёжно висим до второго пришествия, без возможности отмены
Вот только скажи, что у тебя там всё стартует и отменяется мгновенно! |
|
|
|
|
>идёт тупой перебор:
Возможно, как раз этот тупой перебор как раз и пролетает практически мгновенно (особенно на мое 8и-головой серверной конфигурации и соответствующей весьма быстрой FullBuffered-RAM с контролем\коррекцией ошибок), а вот ПОТОМ что-то весьма задумчивое накладывается поверх, и происходит это именно при Беркли-кэше (а тайловые операции уходят по другой ветке)...? |
|
|
|
|
>Вот только скажи, что у тебя там всё стартует и отменяется мгновенно!
19й не пробовал. На 14м, тайловый кэш - стартует за <1 sec. Беркли - >4мин.
Могу проверить на 19м если хочешь. |
|
|
|
(0009246)
|
|
zed
|
|
07-10-2012 10:53
|
|
|
Хочу. Можешь прямо под отладчиком и проверить. Брекпоинтов ты уже понаставил, сейчас запусти новую закачку и смотри в каких строках он будет надолго подвисать. |
|
|
|
|
19й уровень.
старт всего 19го уровня в Tile: меньше минуты, загрузка 100% по ОДНОМУ камню в ВиртБоксе. Уже поехало качать.
старт всего 19го уровня в Berkeley: >10 минут, до сих пор думает, загрузка 100% по ОДНОМУ камню (и это без виртуалки). |
|
|
|
(0009260)
|
|
zed
|
|
07-10-2012 12:11
|
|
Мда, дошло до того, что вот эта вот строка:
VTileIterator := TTileIteratorByPolygon.Create(FPolyProjected);
в TThreadDownloadTiles.Execute для тайлового кэша отрабатывает быстрее, чем для Беркли... казалось бы, а причём тут вообще тип кэша? |
|
|
|
|
Почему ты думаешь, что там затык именно на строке
VTileIterator := TTileIteratorByPolygon.Create(FPolyProjected);
????
С чего ты вообще это взял? |
|
|
|
(0009262)
|
|
zed
|
|
07-10-2012 12:24
|
|
|
Это Parasite так говорит в аське). Он поставил бряк сразу после этой строки и кэш Беркли доходит до неё гораздо медленнее, чем тайловый. |
|
|
|
|
|
Так может там пауза просто где-то раньше. Пусть поставит бряк перед ней. :) |
|
|
|
|
Недолго музыка играла...
При попытке отмены случайно начатого z19 на весь мир - всё опять качественненько зависло, и так и не разродилось хотя честно ждал >3 часа. Ну и до кучи (при окончании терпения и снятии через 3 кнопки) побило соседний качаемый в Беркли кэш.
Тикет в силе. :( |
|
|
|
|
Посмотри именно в отладчике, раз уж он у тебя есть на чем оно застопорилось.
Нужно нажать Pause в делфе, а потом внизу в окне тредов двойным кликом выбрать главный тред. И в стеке смотреть какие функции сейчас выполняются. |
|
|
|
|
>Посмотри именно в отладчике, раз уж он у тебя есть на чем оно застопорилось.
Отладчик в виртуалке - а в ней нету большого беркли-кэша, и свободного места нет чтобы скопировать в туда.
Впрочем, сабж повторяется на ура и без виртуалки - по совету зеда: выбрать весь мир, и попробовать начать качать на 19м уровне или глубже. Получаем висящее окошко по типу приложенного выше (качать не начинает, и ждать можно доооолго). Если там нажать ВЫХОД - то будет сабжевый зависон на как минимум 3 часа, про который я и писал вчера. Можешь попробовать у себя.
А различия во времени старта при разных типах кэша - буду сегодня еще тестить. Напишу, если что найду. Этот тикет не такой критичный, как соседний 1264 - с тем вообще жизни нет... :( |
|
|
|
|
|
Исправил. Теперь интерфейс не подвисает. Но имейте в виду, если выделить весь мир и нажать закачку на 19 зуме, то считать оно будет ооооочень долго. Отменить можно. Но это только закроет окошко закачки, а сам вычислительный тред будет жить пока или не закончит расчет, или не будет закрыто все приложение. |
|
|
|
|
>сам вычислительный тред будет жить пока или не закончит расчет, или не будет закрыто все приложение
А нельзя ему какой-то флаг впендюрить, чтобы можно было его понюхать и прекратить расчёт, а не ждать, пока "или не закончит расчет, или не будет закрыто все приложение".
зы. Ура, хинты пропали )) |
|
|
|
(0009406)
|
|
zed
|
|
09-10-2012 13:55
|
|
|
Вкинуть в TTileIteratorByPolygon экземпляр CancelNotifier да и всё? Можно даже параметром по-умолчанию со значением nil. |
|
|
|
|
|
Лучше пусть кто-то сделает нормальный алгоритм. Эффективнее будет. |
|
|
|
(0009412)
|
|
zed
|
|
09-10-2012 14:04
|
|
|
Кто-то ж говорил, что уже почти всё сделано и лежит себе в тестовом репо ;) |
|
|
|
|
|
Да лежит. Но настроения доделывать просто нету :( Меня эта особенность работы совсем не напрягает. |
|
Clipboard0222.jpg (39,279) 03-10-2012 10:20