|
Notes |
|
|
|
|
За все нужно платить. Сейчас отрисовка карты вынесена в фоновый тред с пониженным приоритетом. Поэтому не блокируется ГУЙ и можно активно двигать карту даже на моем хилом нетбуке. |
|
|
|
(0005273)
|
|
Tolik
|
|
31-01-2012 12:20
|
|
|
А почему загрузка процессора очень мала, в то время как тайлы медленно по одному появляются на экране? Пусть проц. работает :) |
|
|
|
|
>За все нужно платить.
Назовите Вашу цену, коллега? Что же такое важное было вынесено в основной тред, что отрисовка тайлов пред морду юзера стала "тредом с пониженным приоритетом"? :)
Не думаю, что отрисовка всего нескольких тайлов поставит на колени мощный современный процессор. В родных картоприложениях (от владельцев серверов) эти же тайлы прекрасно и намного быстрее отрисовываются даже на тормознутой яве - при этом процессор\память не в пример слабее\меньше. Как пример - андроидный планшет (со сравнимым разрешением экрана что и ноут) с андроидным же ГЕ мало того что ворочает много большим числом слоев над каждым тайлом - так еще и 3Д крутит, крутит через VM, и всё это - на 600мгц камня. Еще и на показ рекламы ресурсы остаются.... |
|
|
|
|
>>За все нужно платить.
> Назовите Вашу цену, коллега?
Скорость отрисовки принесена в жертву отзывчивости пользовательского интерфейса.
ЗЫЖ жду патчей с оптимизацией.
А пока выставляю приоритет этой хотелке.
|
|
|
|
|
>ЗЫЖ жду патчей с оптимизацией.
Оптимизация раз: откатить на "как было", ибо так как сейчас - юзать невозможно, лично у меня прошлый релиз с инета быстрее работает чем такая отрисовка сейчас с винта, просто кошмар какой-то... "Жертва отзывчивости интерфейса" получилась хотя и комом, но слишком большой кровью. Воистину, кровотечение из носа мы полечили путем наложения жгута на шею...
Что остается делать тем, кто не готов на такие жертвы? Лозунги типа "хочешь сделать что-то хорошо - сделай это сам!" тут не порулят, ибо раньше всё бегало нормально и вполне "отзывчиво" для комфортной работы. А потом удивляемся, что никто особо свежие жертвенные версии не тестит. :) |
|
|
|
|
|
Кто не готов пользуется старой версией. Откатывать я не собираюсь. У меня все очень быстро. |
|
|
|
(0005279)
|
|
vasketsov
|
31-01-2012 16:36
(edited on: 31-01-2012 16:47) |
|
Лог монитора дисковой активности как бы намекает нам, что тайлы с диска читаются последовательно друг за дружкой. Приоритет процесса очевидно ни при чём.
20:33:45.8092335 CreateFile NokiaMapCreatorSat\z12\1\x1345\0 SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
20:33:45.8093299 QueryDirectory NokiaMapCreatorSat\z12\1\x1345\0\y600.jpg SUCCESS Filter: y600.jpg, 1: y600.jpg
20:33:45.8093891 CloseFile NokiaMapCreatorSat\z12\1\x1345\0 SUCCESS
20:33:45.8095045 CreateFile NokiaMapCreatorSat\z12\1\x1345\0\y600.jpg SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened
20:33:45.8096472 QueryStandardInformationFile NokiaMapCreatorSat\z12\1\x1345\0\y600.jpg SUCCESS AllocationSize: 32 768, EndOfFile: 31 271, NumberOfLinks: 1, DeletePending: False, Directory: False
20:33:45.8170785 QueryStandardInformationFile NokiaMapCreatorSat\z12\1\x1345\0\y600.jpg SUCCESS AllocationSize: 32 768, EndOfFile: 31 271, NumberOfLinks: 1, DeletePending: False, Directory: False
20:33:45.8171006 ReadFile NokiaMapCreatorSat\z12\1\x1345\0\y600.jpg SUCCESS Offset: 0, Length: 31 271
20:33:45.8171441 CloseFile NokiaMapCreatorSat\z12\1\x1345\0\y600.jpg SUCCESS
20:33:45.8226378 CreateFile NokiaMapCreatorSat\z12\1\x1344\0 SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
20:33:45.8227047 QueryDirectory NokiaMapCreatorSat\z12\1\x1344\0\y600.jpg SUCCESS Filter: y600.jpg, 1: y600.jpg
20:33:45.8227446 CloseFile NokiaMapCreatorSat\z12\1\x1344\0 SUCCESS
20:33:45.8228437 CreateFile NokiaMapCreatorSat\z12\1\x1344\0\y600.jpg SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened
20:33:45.8229502 QueryStandardInformationFile NokiaMapCreatorSat\z12\1\x1344\0\y600.jpg SUCCESS AllocationSize: 32 768, EndOfFile: 32 126, NumberOfLinks: 1, DeletePending: False, Directory: False
20:33:45.8496789 QueryStandardInformationFile NokiaMapCreatorSat\z12\1\x1344\0\y600.jpg SUCCESS AllocationSize: 32 768, EndOfFile: 32 126, NumberOfLinks: 1, DeletePending: False, Directory: False
20:33:45.8496952 ReadFile NokiaMapCreatorSat\z12\1\x1344\0\y600.jpg SUCCESS Offset: 0, Length: 32 126
20:33:45.8497291 CloseFile NokiaMapCreatorSat\z12\1\x1344\0\y600.jpg SUCCESS
20:33:45.8552895 CreateFile NokiaMapCreatorSat\z12\1\x1343\0 SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
20:33:45.8553481 QueryDirectory NokiaMapCreatorSat\z12\1\x1343\0\y600.jpg SUCCESS Filter: y600.jpg, 1: y600.jpg
20:33:45.8553840 CloseFile NokiaMapCreatorSat\z12\1\x1343\0 SUCCESS
20:33:45.8554794 CreateFile NokiaMapCreatorSat\z12\1\x1343\0\y600.jpg SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: N, ShareMode: Read, AllocationSize: n/a, OpenResult: Opened
20:33:45.8558252 QueryStandardInformationFile NokiaMapCreatorSat\z12\1\x1343\0\y600.jpg SUCCESS AllocationSize: 32 768, EndOfFile: 29 571, NumberOfLinks: 1, DeletePending: False, Directory: False
20:33:45.8728980 QueryStandardInformationFile NokiaMapCreatorSat\z12\1\x1343\0\y600.jpg SUCCESS AllocationSize: 32 768, EndOfFile: 29 571, NumberOfLinks: 1, DeletePending: False, Directory: False
20:33:45.8729164 ReadFile NokiaMapCreatorSat\z12\1\x1343\0\y600.jpg SUCCESS Offset: 0, Length: 29 571
20:33:45.8729495 CloseFile NokiaMapCreatorSat\z12\1\x1343\0\y600.jpg SUCCESS
20:33:45.8807836 CreateFile NokiaMapCreatorSat\z12\1\x1346\0 SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened
|
|
|
|
(0005286)
|
|
Parasite
|
01-02-2012 06:53
(edited on: 01-02-2012 06:54) |
|
>тайлы с диска читаются последовательно друг за дружкой. Приоритет процесса очевидно ни при чём.
Насколько я понял - имелся ввиду пониженный приоритет одного треда отрисовки тайлов, а не всего процесса в целом. Да и в Вашем логе кучка тайлов была прочитана менее чем за секунду - что вполне вменяемо, и проблема имхо не в чтении...а вот _отрисованы_ пред очи хомяка они были уже медленно и печально, и в этом и сабж.
2vdemidov: Кстати, а почему у этого треда приоритет именно пониженный? Что если сделать его как минимум "normal", а то и еще повыше (и только на время активного процесса отрисовки тайлов)? Жертва отзывчивости пользовательского интерфейса ж не должна пострадать, он же (интерфейс) не изменится как таковой, и после _мгновенной_ высокоприоритетной отрисовки у него опять будут все системные ресурсы. Если не пойдет - вернуть "как щас", и думать дальше...?
|
|
|
|
(0005287)
|
|
Tolik
|
01-02-2012 06:58
(edited on: 01-02-2012 06:59) |
|
А почему бы не вынести настройку этого приоритета в ini?
Или даже менять его автоматически в зависимости от хилости нетбука?
P.S. Я вот почему-то не вижу разницы в скорости отрисовки на разных компах. Почему на мощном выводит так же медленно?
|
|
|
|
(0005288)
|
|
vasketsov
|
01-02-2012 07:11
(edited on: 01-02-2012 07:13) |
|
>кучка тайлов была прочитана менее чем за секунду
Эта "кучка" - всего 3 штуки. Может действительно речь именно про отображение (и надо лог вперемешку с гуем писать, а не только фс), но тем не менее всё равно непонятно почему последовательно (ибо даже если говорить об одном блине на одном диске на одном проце - всё равно максимум что имеет смысл "синхронизировать" - это ReadFile, ждать CloseFile не надо).
Кроме того, есть и в логе, на что обратить внимание, дубли (QueryStandardInformationFile) и лишние переоткрытия папок (конкретно в этот кусок лога не попало).
>Почему на мощном выводит так же медленно?
Вкупе с полной расслабухой всех ядер на всех процах - это и есть главный вопрос.
|
|
|
|
(0005289)
|
|
Tolik
|
|
01-02-2012 07:35
|
|
|
Кстати, о файлах. При использовании Беркли столько файлов открывать не надо, они ж наверно в кэш-памяти находятся. Отрисовка работает так же. |
|
|
|
|
>но тем не менее всё равно непонятно
Это уже тема для другого бага, имхо. В данном конкретном случае тормозит _отрисовка_, и она тормозит даже тогда когда читаем с RАМдиска.
Да и сводит-то ночнушка (то же чтение тех же тайлов) вроде как без изменений и тормозов, трабла именно в перерисовке экрана при таскании его курсором\зуммировании.
>Вкупе с полной расслабухой всех ядер на всех процах - это и есть главный вопрос.
+1, на _восьми_процессорном Xeon'e+RAMдиске при такой работе в таскманагере вообще активности САСа не видно. Казалось бы - жжги их все восемь покуда не задымятся, ан нет. Робит точно так же печально, как и на старом однопроцессорном\одноядерном селероновом ноуте (и там активность САСа в таскманагере уже чуточку видна, но всё равно не более 1-2% в среднем, 10% в пике).
Короче - низачот. :( |
|
|
|
(0005780)
|
|
Tolik
|
02-03-2012 10:15
(edited on: 02-03-2012 10:17) |
|
Замечу, что за последний месяц при таскании карты мышкой загрузка процессора сильно выросла, а скорость отрисовки тайлов не изменилась.
Кажется, пора открывать новый реквест - на оптимизацию кода по загрузке процессора :(
|
|
|
|
|
Стало часто кидаться EOutOfMemory (при декомпрессии png, но думаю это неважно).
А сасе это происходит на строке
spr.SetSize(VTargetImageSize.X, VTargetImageSize.Y);
внутри
function TMapType.LoadBtimap
то бишь при вполне заурядной операции.
Возможно связано с кэшем в памяти, всё только копится и не очищается, у мну в этот момент WorkingSetSize у саса был больше 2 гигов. Что конечно просто ахтунг. |
|
|
|
|
|
Про утечки памяти в отдельный инцидент, а это Хотелка. |
|
|
|
|
>Сделать боле быструю отрисовку тайлов на экране
Это совершенно не то, что рапортовалось в моем первом тикете, и далее - в ныне удаленном обсуждении.
Ничего СДЕЛАТЬ в пределах данного тикета Я НЕ ПРОСИЛ. Я лишь рапортовал о найденном БАГЕ.
Какая жалость, что он никому так и не стал интересен.
/CLOSED. |
|
|
|
(0005910)
|
|
Tolik
|
|
07-03-2012 11:16
|
|
|
Народ "реквистирует оживление вопроса": 0001205 |
|
|
|
|
>Народ "реквистирует оживление вопроса": 0001205
Угу.
Тогда пааапрашу не менять начальное описание. Это БАГ, а не хотелка. Когда я захочу хотелки - я так оную и обозначу изначально.
Для справки: баг - это то, что УЖЕ есть, и от чего надо избавиться. Хотелка - это то, чего ЕЩЕ нету - но чего хотелось бы.
Обсуждаемое УЖЕ есть, и от тормозов обсуждаемого хотелось бы таки избавиться. |
|
|
|
|
|
Баг, это когда что-то работает не так как задумал автор. А это фитча. |
|
|
|
|
>Баг, это когда что-то работает не так как задумал автор. А это фитча.
Я понятия не имею, как и о чем задумывал аффтар, коль скоро он нигде не соизволил озвучить это - и если отваливается то, что прекрасно работало, то это баг по типу "руки из пятой точки", а не фича. Уж как на духу - отрисовка ХХ тайлов 256х256,указанных в кэше проги, на 8ипроцессорном Хеоне с 32 гигами РАМы _с тормозами_ (когда там летает намного, НА ПОРЯДКИ более тяжелый Автокад, причем параллельно!) - это полный атас.
Фича - это "делать что-то полезное и нужное новым, недокументированным аффтарами способом". Делать "тормоза документированными способами" - это косяк и оксюморон. Поспорь, поспорь со старым фидошником на тему фичеобеспечения и нетерпимости к работавшему ранее, а ныне отломанному... |
|
|
|
|
>работает не так как задумал автор
То есть автор задумал замедление работы? ))))
В плагине для GPSMapEdit я гружу тайлы из кэша саса штатными средствами саса (то есть работает кэш тайлов в памяти) и рисую их на HDC руками по одному в один поток (прочитал-нарисовал-прочитал-нарисовал-...). Это получается несравнимо быстрее чем в сасе. Если тайлы практически не масштабируются (то есть они всё равно масшабируются до текущего масштаба GME, там масштаб не по зумам, так что это лишний повод тормозить тайлам в GME, сейчас важно что тайлов столько же рисуется, сколько рисует САС примерно на таком же зуме) - там это просто мгновенно. В отличие от. |
|
|
|
|
>>работает не так как задумал автор
> То есть автор задумал замедление работы? ))))
Автор пожертвовал скоростью обновления изображения на экране в пользу отзывчивости интерфейса. Сейчас, даже если файлы у вас на очень медленном диске SAS будет работать нормально, просто изображения будут появляться с большой задержкой. А попробуйте то же самое в GPSMapEdit с вашим довеском. |
|
|
|
|
vdemidov, прекращай детство с редактированием хидера тикета.
Либо принимай тикет так как написано, либо закрывай на мороз. На дебильный статус ХОТЕЛКА я не согласен и не претендовал изначально, а постоянно менять хидер на изначально написанное мне времени нет. Ей-Богу, детсад уже какой-то начался. Не хочешь - не фиксь, мне без разницы - и тем хуже для проекта (постепенно скатывающегося в сраное гуано, если кому-то интересна моя локальная точка зрения). Лично у меня и старые версии пока что рулят, если что.
Факта БАГА это не отменяет, и рано или поздно фичить оный кому-то да придется. Вона, уже новый дубль-тикет по теме. |
|
|
|
|
>Автор пожертвовал
Медалю автору, медалю!!
Что-то я не помню в пределах проекта открытого голосования "Чего Вы хотите: тормозов отрисовки или отзывчивости интерфейса?", с отрывом победившего в первом же туре.
>если файлы у вас на очень медленном диске SAS
SAS (оно же Serial-SCSI) много быстрее среднестатистического "секретулькиного" SATA, и изначально предназначалось для server-side применения. Так, для справки.
>просто изображения будут появляться с большой задержкой.
В старой версии САСа они появляются БЕЗ задержки на том же диске, на том же кэше, и ровно с теми же (байт-в-байт) настройками.
Я ни в жизнь не поверю, что чтение и обработка 20и отрисовываемых тайлов занимает 8 (ВОСЕМЬ) секунд на современном железе, протом все тайлы уже в РАМ-кэше.
Благо что на старой версии это отрисовывается ровно мгновенно - стоит лишь подменить экзешник саса в папке. |
|
|
|
|
>Это ты прекращай детство
Боже, как предсказуемо...
Я его закрыл еще вчера, кстати.
PS: на будущее предлагаю ставить всем БАГАМ статус ХОТЕЛКА: ведь мы же ХОТИМ, чтобы баг был изничтожен, не так ли? А куча заискивающих хотелок выглядит совершенно не так, как куча аццких багов - не так ли?
Тьху. Детсад.... |
|
|
|
|
>Я ни в жизнь не поверю, что чтение и обработка 20и отрисовываемых тайлов занимает 8 (ВОСЕМЬ) секунд на современном железе, протом все тайлы уже в РАМ-кэше.
Ты что с дуба рухнул. На моей хилой машине в один поток оно занимает максимум 1.5 секунды на отрисовку экрана с включенной картой и без слоев.
|
|
|
|
|
>Ты что с дуба рухнул.
ВОООТ!!!!!! Наконец-то!!! А ты думаешь - тикет просто так появился, и просто так НАСТОЯТЕЛЬНО остается в статусе "БАГ"?
Вся тема как раз в том, что отрисовку тайлов я _сейчас_ наблюдаю глазками. То есть - отрисовали квадратик, подумали, отрисовали второй, подумали...итд.
При размере экрана в 2560px по длинной - хаполнение экрана, наблюдаемое глазками - просто БЕСИТ. Притом что в предыдущей версии все заполняется на раз!
Если бы оно просто _немножко_ подтормаживало - я бы и тикет не стал заводить бы. Время дороже. |
|
|
|
|
|
Давай видео этого процесса. |
|
|
|
|
|
И еще запусти дебажную версию, полазь по карте, а потом сделай скриншот окошка Debug View |
|
|
|
(0005931)
|
|
Tolik
|
07-03-2012 13:37
(edited on: 07-03-2012 13:53) |
|
> Тогда пааапрашу не менять начальное описание. Это БАГ, а не хотелка.
Parasite, я что-то не понял. Я его переоткрыл именно как баг и с первоначальным названием. И vdemidov сделал ему confirm и уж как бы согласился.
К чему был этот пост 0001145:0005913 ??
|
|
|
|
(0005935)
|
|
Parasite
|
07-03-2012 13:46
(edited on: 07-03-2012 13:51) |
|
>Давай видео этого процесса.
Ну вот еще, щас всё брошу и начну ставить писАлки видео...
Давай синтетически: размер экрана = 2560\1920\24, карта - ASTER_bg, поверху - импортнутый KML заполнения ASTER (~ 22тыс объектов). Всё касательное САСа (включая его самого + кэш) - на RАМ-диске.
Время от нажатия [+] или [-] на панельке зума САСа до финального отображения всего и вся СЕЙЧАС - ~ 8сек. Процесс отрисовки экрана наблюдается глазками и сопровождается матюками.
В предыдущей версии (даже в релизе!) - отрисовка хоть и несколько думает после нажатия (не более секунды на весь экран), но отрисовывает весь экран сразу и МГНОВЕННО, считая от начала процесса отрисовки.
Прошу вернуть мгновенную "старую поэкранную" отрисовку вместо "медленной задумчиво-поквадратной" новой.
|
|
|
|
|
>К чему был этот пост № 5913 ??
К vdemidov'ским изменениям хидера тикета. |
|
|
|
|
> Ну вот еще, щас всё брошу и начну ставить писАлки видео...
Ну не хочешь не нужно. Я уж тем более разбираться не буду. |
|
|
|
|
>Ну не хочешь не нужно. Я уж тем более разбираться не буду.
Я не про то. Я к тому, что ставить писАлку видео - тот еще порн (на моей стороне), так что предлагаю пока что синтетически.
Проблема-то имеет место быть - независимо от видео. |
|
|
|
|
> Проблема-то имеет место быть - независимо от видео.
Увы я этого не вижу. Попробуй для начала поотключать все слои, сетки, метки и тд. Вплоть до миникарты. |
|
|
|
(0005943)
|
|
Tolik
|
|
07-03-2012 14:12
|
|
Обратите внимание на фразу rudepravo из 0001205
"Откатил последнюю ночную сборку на .5122 - всё ок."
Думается, надо проанализировать последние коммиты, что могло так повлиять? Хотя я на своём железе не замечал большой разницы между 5122 и другими.
rudepravo, а можете точнее сказать, на какой именно версии произошёл качественный скачок? Можете проверить все версии от 5122 до 5163? |
|
|
|
|
>Попробуй для начала поотключать все слои, сетки, метки и тд. Вплоть до миникарты.
Делал. Давно. Изменения - минорны.
Мажорное изменение дает замена экзешника с ночнушки - на релизный (при неизменном всём остальном). Всё (сабжевое) начинает просто летать на экзешнике релиза.
К сожалению, на релизе свои траблы (например сваливание при скролле карты), так что полноценно него юзать тоже не получается.
Но карту отображает _моментально_. |
|
|
|
|
Про старую версию можешь забыть. Точнее пользуйся, если хочешь, но хватит рассказывать что она летала.
Как минимум жду принтскрина окна с Debug Info |
|
|
|
|
>максимум 1.5 секунды на отрисовку экрана с включенной картой и без слоев
Ну вот а представь ситуацию, что сейчас оно отображается из кэша в памяти медленнее, чем раньше скачивалось и отображалось. Монитор 1920x1200, входов DVI у него много, так что проблема эквипенисуальна относительно замены NVIDIA на ATI. О полутора секундах остаётся только мечтать.
>даже если файлы у вас на очень медленном диске SAS будет работать нормально
Немного не так. Сас не умрёт в надежде дождаться чтения тайла. Это конечно хорошо. Тем более что хранилища тоже могут быть далеко и плоходоступны. Но проблема не в этом. Суть в том, что даже если рисовалку вынести в отдельный поток и в нём читать файлы и рисовать их - будет и то быстрее. Там _очевидно_ где-то косяк скрылся.
>попробуйте то же самое в GPSMapEdit с вашим довеском
А смысл пробовать, а так всё понятно что будет. Я ж написал, там один поток и всё по очереди. Только это совсем не оправдание. |
|
|
|
|
>жду принтскрина окна с Debug Info
Та не вопрос...но куда конкретно нажимать?
>Там _очевидно_ где-то косяк скрылся.
Что я и пытаюсь доказать изначально!
Куда нажимать(c)? |
|
|
|
|
> Куда нажимать(c)?
Ты не поверишь: в дебажной версии в главном меню View\Debug Info |
|
|
|
|
Cейчас кэш с Гугла докачается, проверю.
Вот что есть в наличии
SAS.Planet.Nightly.120206.4992.7z
SAS.Planet.Nightly.120208.5002.7z
SAS.Planet.Nightly.120209.5019.7z
SAS.Planet.Nightly.120210.5023.7z
SAS.Planet.Nightly.120212.5032.7z
SAS.Planet.Nightly.120213.5035.7z
SAS.Planet.Nightly.120214.5045.7z
SAS.Planet.Nightly.120216.5058.7z
SAS.Planet.Nightly.120217.5066.7z
SAS.Planet.Nightly.120218.5075.7z
SAS.Planet.Nightly.120221.5082.7z
SAS.Planet.Nightly.120224.5092.7z
SAS.Planet.Nightly.120227.5102.7z
SAS.Planet.Nightly.120229.5122.7z
SAS.Planet.Nightly.120303.5144.7z
SAS.Planet.Nightly.120304.5146.7z
SAS.Planet.Nightly.120305.5149.7z
SAS.Planet.Nightly.120307.5163.7z |
|
|
|
(0005964)
|
|
rudepravo
|
10-03-2012 17:09
(edited on: 10-03-2012 21:37) |
|
Добрался до проведения тестов.
Исходная конфигурация Pentium-M IV 2.2Ghz, 1Gb памяти, чистая перезагрузка, никаких других программ не загружено. Запуск SASPlanet с диска Truecrypt, кэш - файловый. Включено отображение Google Maps спутник, со слоями Google Hybrid и Wikimapia, а также выделена для скачивания область, занимающая половину экрана.
Масштаб - z8.
Все тестируемые версии - ночные сборки.
4992 - летает
5092 - небольшие замедления (примерно 5-10%)
5122 - такие же замедления как в 5092
5144,5146,5149 - наступают тормоза (отрисовка вывода на экран увеличилась раза в три, 100% загрузка процессора)
5163 - скорость отрисовки увеличилась, и составляет примерно 1.5-2х от 5144
5181 - без изменений по сравнению с 5163
|
|
|
|
(0005970)
|
|
Tolik
|
|
11-03-2012 05:06
|
|
По названию коммитов (с 5123 по 5144) трудно понять, какой из них так повлиял на скорость.
Скорее всего, какой-то из них внёс баг.
Можно сбилдить, например, версии 5125, 5130, 5135, 5140 и погонять их...
Это если метод пристального вглядывания не поможет :) |
|
|
|
(0005972)
|
|
vasketsov
|
11-03-2012 08:04
(edited on: 11-03-2012 08:11) |
|
Ну в общем я полечил эту багу у себя. Как vdemidov сольёт ветки в репо - так и исправлю.
зы. Ну то есть конечно я не уверен что все тормоза устранятся, но у меня стало ощутимо быстрее рисоваться (один спутник без слоёв).
|
|
|
|
(0005973)
|
|
Tolik
|
11-03-2012 08:59
(edited on: 11-03-2012 09:00) |
|
Ну и в чём там собака порылась?
|
|
|
|
|
|
Неверный выбор примитива синхронизации в 2-х местах (третье под подозрением, пока там не правил), слишком всё "засинхронизировано". Собственно я это и предполагал изначально. Просто сегодня было время посидеть и поглядеть. За конкретную ревизию не скажу, смотрел под отладчиком чтение тайлов, а не по ревизиям. |
|
|
|
(0005976)
|
|
Tolik
|
|
11-03-2012 09:18
|
|
> За конкретную ревизию не скажу
Жаль, может есть и другая причина.
А в 5122 по-другому засинхронизировано? |
|
|
|
|
Оба "косяка" до 5092. Просто накопилась критическая масса. А 5122 вообще сюда никакого отношения не имеет.
Повторю, щас у меня всё опять летает. А раньше - даже уже закэшированные в память тайлы рисовались медленно и печально. Залью - останутся претензии - тогда и будем обсуждать. |
|
|
|
(0005984)
|
|
Tolik
|
|
12-03-2012 07:36
|
|
|
А почему vdemidov никак не смержит vasketsovские коммиты 4-дневной давности? |
|
|
|
(0005986)
|
|
Tolik
|
|
12-03-2012 07:45
|
|
> Ну в общем я полечил эту багу у себя
А можно нам попробовать, пока в ночнушке не исправлено? |
|
|
|
(0005987)
|
|
vasketsov
|
12-03-2012 07:57
(edited on: 12-03-2012 10:05) |
|
>коммиты 4-дневной давности
Судя по тому как после моей ревизии 5163 он напихал своих 13, не замерджив - делаю вывод о том, что не всё пока окончательно у него в ревизиях.
>можно нам попробовать
Да можно конечно, приаттачил SASPlanet_Sync.rar. Размер меньше стал после переписывания вебброузера и выкидывания из него ненужного (и вкидывания мозиллы, он пока никак не переключить).
|
|
|
|
(0005991)
|
|
Tolik
|
|
12-03-2012 10:49
|
|
|
Лично я разницы (с 5197) не заметил :( |
|
|
|
(0005992)
|
|
vasketsov
|
12-03-2012 11:08
(edited on: 12-03-2012 11:13) |
|
Лучше всего тест проводить на только что загруженных в оперативную память (кэш в памяти) тайлах. У меня они стали отрисовываться быстрее, чем я могу сказать "черничный пирог". Раньше было не так.
Кроме того, я не гарантировал, что обязательно всё полечится. Полечился конкретный кусок (точнее несколько), тормоза могут быть и в другом месте. Зато сейчас простой "синтетический" тест прога у меня проходит. При перерисовке карты CPU вырастает до 100%. То есть прога ему не мешает лишними ожиданиями на примитивах синхронизации.
|
|
|
|
(0005993)
|
|
Tolik
|
|
12-03-2012 11:31
|
|
Я так и делаю: гоняю вправо-влево, зажав клавишу со стрелкой, так что всё в памяти. Смотрю на скорость движения, рывки, загрузку проц., белые квадраты. В обеих версиях одинаково: движется довольно быстро, но неравномерно, рывки очень неприятные, белых квадратов и полос нет вообще, загрузка 60-65%.
На моём железе и так не было тормозов в 8 сек, надо чтобы Parasite и rudepravo проверили. И чтобы описали подробнее, как именно тестируют и какой результат. |
|
|
|
(0005994)
|
|
vasketsov
|
12-03-2012 12:31
(edited on: 12-03-2012 14:12) |
|
>загрузка 60-65%
Это только подтверждает, что затык в другом месте.
Приаттачил SASPlanet_Sync2.rar для дальнейших игр.
|
|
|
|
|
C секундомером проверил (2 запуска, PIV-2.2Ghz, 1Mb,файловый кэш,слои Google Maps, Google Hybrid, Wikimapia). На половину отображаемой карты выделен полигон для скачивания. Окончание запуска - отображение последнего полигона Викимапии
4992 - 13.52с, 13.40с
5122 - 14.71, 14.26
SASSync2 - 20.74, 16.82, 15.50 |
|
|
|
|
>Окончание запуска - отображение последнего полигона Викимапии
Не то. Беда = 'Очень медленно и печально стали перерисовываться тайлы на экране'. Это и надо тестить. А не время запуска. |
|
|
|
(0006001)
|
|
rudepravo
|
13-03-2012 01:00
(edited on: 13-03-2012 01:01) |
|
Время запуска тоже критичная величина. Замедление при запуске на 54% не есть гуд.
Тест скролла экрана на целый экран(карта полностью перерисовается), с рисованием карты заполнения тайлами - пойдёт?
|
|
|
|
(0006005)
|
|
Tolik
|
|
13-03-2012 04:45
|
|
Я опять на своём компе не заметил никакой разницы.
Запускается, кстати, любая версия у меня за 2.5 сек. Откуда 20?? Может, меток 100 мегабайт? |
|
|
|
(0006012)
|
|
Parasite
|
13-03-2012 05:15
(edited on: 13-03-2012 05:21) |
|
>Ну в общем я полечил эту багу у себя.
О. Гуд ньюз, бро.
>Запускается, кстати, любая версия у меня за 2.5 сек. Откуда 20??
Лично у меня запускалась намного медленнее. Не 20, но секунд 10 точно уходит.
>надо чтобы Parasite и rudepravo проверили.
Не вопрос. Сегодня вечером и проверим.
Да, кстати - вот еще хороший тест: импортнуть пару десятков тысяч меток в новую категорию, немножко поюзать на карте, а потом СТЕРЕТЬ ЭТУ КАТЕГОРИЮ (со всеми метками). Для опытов рекомендую КМЛ с 22тыс меток от ASTER:
http://sasgis.org/forum/viewtopic.php?f=21&t=1848
Релиз - стирает всю категорию мгновенно. Сабжевая ночнушка стирала секунд 30 (при этом весь остальной САС висел в состоянии "И пусть вся Европа подождет...!").
Импорт у ночнушки тоже заметно печальнее чем у релиза.
|
|
|
|
(0006016)
|
|
Tolik
|
|
13-03-2012 05:30
|
|
|
Про импорт это вообще-то офтопик (как и про скорость запуска и удаление), но проверь, есть ли xerсes*.dll |
|
|
|
|
>Про импорт это вообще-то офтопик (как и про скорость запуска и удаление)
Я не дам гарантии, что оно не связано друг с другом. В любом случае, у меня оно проявилось одновременно и в пределах одной версии ночнушки, и в общем и целом по факту юзания оной этот весь тикет и появился - а там уж разрабам виднее, что и куда там одно через другое завязано.
Наше дело - сообщить, авось чем-то да поможет выловить баг. Обсуждать сие я тут и не предлагаю. |
|
|
|
|
>Замедление при запуске на 54% не есть гуд
Там после 5122 ещё два десятка ревизий. Но если это из-за моего "лечения" - значит там куда более серьёзные архитектурные проблемы. Потому что если у машины, газующей с тормозом, убрать тормоз - она обычно едет быстрее.
На всякий случай - сравнивать надо и SASPlanet_Sync.rar и SASSync2, там разное. |
|
|
|
(0006043)
|
|
Parasite
|
13-03-2012 13:55
(edited on: 13-03-2012 13:58) |
|
>На всякий случай - сравнивать надо и SASPlanet_Sync.rar и SASSync2, там разное.
Докладуюсь:
Ничего визуально не изменилось - наоборот, даже стало субъективно немножко печальнее ИМХО. Но ненамного по сравнению с ночнушкой.
Никакой разницы между sync1 и sync2 замечено не было. Сейчас я даже вижу глазками(sic!) как бы двойную перерисовку тайлов: сперва отображается тайл то ли с некоторой мерой полупрозрачности, то ли самую малость залитый белым. И уже потом, во второй проход, он "проявляется" (отображается в нормальном цвете), и у него появляются включенные САСом границы (сетка тайлов на экране). В предыдущей ночнушке оно хоть и тормозило, но не "визуально-дважды".
Перезуммирование экрана (при наличии всех тайлов в кэше) - ~ 5...8сек визуально в зависимости от плотности инфы в жпегах (как я понимаю), отрисовка к.тайла видна глазом. При перезуммировании стала наблюдаться заметная нагрузка на один из процессоров (из 8и свободных) - до 50% на один CPU в пике, остальные так и стоят свободными. Раньше этого пика не было.
Перераспределение процесса всего лишь на 1 CPU (affinity) ничего не меняет. Все остается абсолютно так же.
Холодный старт обоих sync'ов (без ничего касательного САСа в системном кэше, но с рам-диска) - 13...15сек визуально. С секундомером - не засекал.
Релиз - запуск 4сек, отображение карты _летает_ при прочих равных (менялись только экзешники).
Карта - aster_bg, два слоя сверху - aster_zapolnenie+aster_countries, ссылка на все три - выше. Размер экрана 2560х1920, Вин2003Серв, "число тайлов за границей экрана=0" в настройках САСа.
|
|
|
|
(0006044)
|
|
zed
|
|
13-03-2012 13:59
|
|
|
А в окошко "Debug info" так никто и не заглянул... а там между прочим реальные циферки по отрисовке и секундомеров не нужно. |
|
|
|
|
На всякий случай приложил картинку из taskmgr.
Так должна выглядеть загрузка CPU при таскании карты в сасе на одном зуме (сначала пик - загрузка саса, потом пауза, потом потаскал в пике до 98% CPU, потом опять пауза и скриншот). И по ядрам сас успешно разбежался. Любые отступления от таого графика - беда.
Ну я ей богу не знаю, почему у меня полечилось, а у вас нет. Ну то есть догадываюсь, что просто где-то ещё собака порылась.
>реальные циферки по отрисовке
Куда именно надо смотреть? По идее надо иметь инфу о том, сколько времени уходит на конкретную рутину, то бишь профайлер. Там оно и есть? |
|
|
|
(0006048)
|
|
zed
|
|
13-03-2012 14:25
|
|
|
На дебажной версии: View->Debug Info. Да, там как раз мини-профайлер для определённых процедур. |
|
|
|
(0006049)
|
|
Parasite
|
13-03-2012 14:27
(edited on: 13-03-2012 14:30) |
|
>На всякий случай приложил картинку из taskmgr.
>Так должна выглядеть загрузка CPU при таскании карты в сасе на одном зуме (сначала пик - загрузка саса, потом пауза, потом потаскал в пике до 98% CPU, потом опять пауза и скриншот). И по ядрам сас успешно разбежался. Любые отступления от таого графика - беда.
Лови мой скрин.
На cpu#1 идет параллельная эксклюзивная конвертация 5.1 flac - в него не смотри. :)
Смотри на cpu#3, на кой судя по всему САС и сел (хотя ему разрешены все кроме #1), а также некоторый пик на #2. Пики - это переход работающего САСа с 10го зума на 11й (еще не бывший в кэше) путем тычка в кнопке [+].
Другие процы сасом задействованы не были.
>потом потаскал в пике до 98% CPU
У меня САС никогда не занимал более 50% _одного_ проца. В пике. Обычно - 1...5%, иногда - на неск.камней одинаково, но и не более того.
|
|
|
|
|
Ну если все красоты, слои и миникарта отключены - очевидно тормоза будут внутри /TMapMainLayer/BgDraw. В частности после таскания у меня там среднее время раз в 30 больше, чем визуально в сумме остальные.
Походу надо наделать ещё "счётчиков" внутри /TMapMainLayer/BgDraw, а то нифига не понятно. Да и судя по всему из времени не вычитаются "внутренности", когда вызов уходит под другой счётчик в дочерних рутинах. Эх, ещё б пустые счётчики "сворачивались". |
|
|
|
|
>Ну если все красоты, слои и миникарта отключены
Красот нет.
Слоев - 2 (выше перечислены).
Миникарта - есть.
>когда вызов уходит под другой счётчик в дочерних рутинах
Я в это уже не ездун. Какую конкретно цифирку сказать? Эта зараза не принтскринится в _один_ скриншот, а составлять клееную портянку прямо сейчас - не с руки... |
|
|
|
|
|
Блин. Нужно срочно делать экспорт данных Debug Info в какой-то csv. |
|
|
|
|
Да визуально просто погляди, поверю и на слово.
Сбрасываешь, таскаешься, рефрешишь - ищешь сильно максимальное значение.
У мну /TMapMainLayer/BgDraw ___СИЛЬНО___ больше остальных.
Если тот же кал - буду делать счётчиков внутри этого счётчика. |
|
|
|
|
Немного поездил по карте\зумам
сократил до 3х зн.после запятой
-----------------
/TMapMainLayer/PosChange 32 09.313 298.022
/TMapMainLayer/BgDraw 30 09.371 281.133
Все остальные значения - ниже единицы. Многие - шибко ниже (0.001ххх) |
|
|
|
(0006059)
|
|
vdemidov
|
13-03-2012 15:29
(edited on: 13-03-2012 15:32) |
|
Опача. "/TMapMainLayer/PosChange 32 09.313" Это жесть. Такого не должно быть, потому что такого не должно быть никогда.
PS:
И может все таки /ViewState/PosChange ?
|
|
|
|
(0006060)
|
|
vasketsov
|
13-03-2012 15:31
(edited on: 13-03-2012 15:33) |
|
Мда. Наделал счётчиков внутри - и прифигел неслабо от результатов. Ща напишу с картинкаме.
зы. У меня PosChange относительно BgDraw раз в 50 меньше. Это так к слову.
|
|
|
|
|
>Такого не должно быть, потому что такого не должно быть никогда.
Сие есть реальность, данная нам в ощущениях. (с)
Куда дальше нажимать? |
|
|
|
|
>Куда дальше нажимать?
ХЗ. Одно могу точно сказать, что оптимизировать TMapMainLayer/BgDraw в твоем случае бесполезно. Поскольку у тебя он реально занимает 0,06 секунд на одну отрисовку.
Все остальное время ждет окончания /ViewState/PosChange |
|
|
|
|
>зы. У меня PosChange относительно BgDraw раз в 50 меньше. Это так к слову.
К слову это так и задумано. Оно должно занимать максимум десятки милисекунд. |
|
|
|
|
>Все остальное время ждет окончания /ViewState/PosChange
А почему в релизе - моментально? |
|
|
|
|
От чего _системно_ зависят PosChange и BgDraw? Может, они хотят эксклюзивного доступа к железу, Dx или еще какой пакости? У меня винда в кластере (читай - распределенная песочница), и реального доступа к фактическому железу у нее _нет_ и никогда не было. Может быть, тут затык?
Но релизу это почему-то не мешает, как и всем предыдущим версиям. |
|
|
|
|
>У меня винда в кластере (читай - распределенная песочница)
Вот например приаттаченая к воркспейсу 8я винда (чтоб ей неладно) там же, параллельно. |
|
|
|
(0006068)
|
|
vasketsov
|
13-03-2012 15:51
(edited on: 13-03-2012 17:09) |
|
Разбил TMapMainLayer.DrawBitmap на куски со счётчиками (вне счётчиков ничего не осталось). Каринка приаттачена (SingleDrag_BgDraw.jpg). Начал сомневаться в своих знаниях математики :oЮ
зы. QueryPerformanceCounter:
On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.
Приаттачил SASPlanet_BgDraw.rar с дополнительными счётчиками внутри BgDraw.
Тестировать эту процу надо при отключенных миникартах и прочей фигне типа сетки. Только карта или карта+слои.
зы. Путём экспериментов выяснилось, что у меня PosChange становится равным BgDraw (я не меняю зум, а только таскаю карту вправо-влево), если таскать карту не отточенными рывками, а медленно, держать нажатой мышку, с "полётом" карты после отпускания. Так что беда в BgDraw.
Вернее не совсем. У меня есть мысль. Кардинальная. Закомментировал обращения к FCS внутри TInternalPerformanceCounter.FinishOperation. Значения времён стали в разы меньше. При том что конкретно к этому счётчику параллельных обращений нет. Так что вот такие пироги.
ззы. для тестирования системного счётчика производительности приаттачил ZwPerfCounter.rar (запускаем - и результат в студию). Для сравнения мой:
Done $FF times in 0.000236482569712
Frequency = 14318180
|
|
|
|
|
>Разбил TMapMainLayer.DrawBitmap на куски со счётчиками
В случае Паразита проблема не в этой функции. Проблема где-то в /ViewState/PosChange. А вот где я даже не представляю.
>А почему в релизе - моментально?
Ну например в релизе используется старая версия библиотеки Graphics32 без каких-то оптимизаций, которые хотят доступа к железу и без него конкретно глючат. |
|
|
|
(0006070)
|
|
Parasite
|
13-03-2012 17:12
(edited on: 13-03-2012 17:16) |
|
>Ну например в релизе используется старая версия библиотеки Graphics32 без каких-то оптимизаций, которые хотят доступа к железу и без него конкретно глючат.
Напомню, что (в моем случае) релиз от ночнушки отличался _только_ экзешником. Если там были какие-то обновления либ между релизом и ночнушкой - оно не просило\не еррорило, и все без исключения либы (и все остальное - инишник, метки, кэш итд) оставались из состава релиза даже при юзании ночнушкиного экзешника в той же папке.
|
|
|
|
|
|
Из-за чего может быть (при одном перетаскивании карты по тайлам в памяти), что BgDraw примерно 0.3, другие счётчики почти по нулям, а картинка перерисовывается секунду? Куда ещё счётчик вставить имеет смысл? |
|
|
|
(0006072)
|
|
rudepravo
|
13-03-2012 19:06
(edited on: 13-03-2012 19:21) |
|
>Запускается, кстати, любая версия у меня за 2.5 сек. Откуда 20?? Может, меток 100 мегабайт?
Меток 5 штук ровно. Выделена область Rus-Ua-Blr. Да и компутер небыстр. Но замедление старта присутствует и доставляет неудобство.
U:\SASPlanet>ZwPerfCounter.exe
Done $FF times in 0,000483581013788
Frequency = 3579545
U:\SASPlanet>ZwPerfCounter.exe SASPlanet.exe
Done $FF times in 0,000599517536447
Frequency = 3579545
U:\SASPlanet>ZwPerfCounter.exe
Done $FF times in 0,000493917523037
Frequency = 3579545
Версия 4922 на старте
TWikiLayer/BGDraw 1 0.82759
TMainLayer/BGDraw 1 1.556286
TMiniMapLayer/BGDraw 2 0.78165884
Версия из шапки SASPlanet_BgDraw.rar
Отрисовка затормозилась как-то совсем печально, судя по цифрам
TWikiLayer/BGDraw 1 4,7399
TMainLayer/BGDraw 1 3,63160
TMiniMapLayer/BGDraw 1 0.22012
А со временем холодного старта новый тикет создавать, или этим обойдёмся?
|
|
|
|
|
>совсем печально, судя по цифрам
Ещё раз ВНИМАТЕЛЬНО тестируемся. Хотя если вы не заинтересованы в результате.............
1. Отключаем все слои, миникарту, сетки генштаба и прочие, качалки и другие феньки. Остается ТОЛЬКО базовая карта.
2. Шаримся по ней вправо-влево, чтобы тайлы залетели в память.
3. Открываем окошко DebugInfo и жмём там Reset (для сброса счётчиков). Окошко НЕ ЗАКРЫВАЕМ.
4. Берём карту мышкой и тащим вбок чтобы она РОВНО ОДИН РАЗ перерисовалась. Не таскаем её, не бросаем чтобы она сама "летела". А чётко нажали-сдвинули-отпустили.
5. Жмём в окне DebugInfo на кнопку Refresh.
6. Смотрим глазами значение BgDraw. Мысленно сопоставляем с РЕАЛЬНЫМ временем перерисовки. По вкусу ругаемся...
7. На всякий случай смотрим в счётчики с именами /TileLoad/* - там должно быть пусто. Если нет - плохо выполнили пункт 2 - надо повторить. Также смотрим чтобы BgDraw выполнилось ОДИН раз. Если нет - плохо выполнили пункт 4 - надо повторить.
>Frequency = 3579545
В 4 раза меньше чем у меня.
>Done $FF times in 0,000599517536447
Вдвое дольше (((
В обоих случаях плохо.
зы. Запускать можно было просто ZwPerfCounter.exe.
Щас новую версию саса для игр приаттачу. |
|
|
|
|
|
А сделайте заодно чтобы можно было перфкаунтеры куда-то в файло сливать, а то неудобно цифири с окошка набивать вручную |
|
|
|
(0006075)
|
|
vasketsov
|
13-03-2012 20:40
(edited on: 13-03-2012 20:42) |
|
Приаттачил SASPlanet_DebugInfo.rar.
Копирование счётчиков не в файл, а в буфер обмена. С табуляциями и переносами строк (если выделено более одной строки). Все ячейки по ширине выделять не обязательно. Как сюда скопируется - необходимо будет добавить табуляций в нужные места для читаемости.
зы. Показ меток и текущего выделения тоже может играть свою роль, их тоже отключаем.
|
|
|
|
|
Выделил область, нажал Ctrl-C, ничего в клипборд не запихалось. Пробовал Shift-Del, Ctrl-X - тот же самый результать. Доктор, это я такой талантливый или что-то делаю не так?
Может всё-таки прикрутить там кнопочку save to file, и тупо на диск C: писать? |
|
|
|
(0006077)
|
|
vasketsov
|
13-03-2012 21:09
(edited on: 13-03-2012 21:25) |
|
>что-то делаю не так
Ну может русский язык включен. Мне отсюда не видно.
Добавлена кнопка. Файл SASPlanet_PerfCntrsSaver.rar.
|
|
|
|
|
>Напомню, что (в моем случае) релиз от ночнушки отличался _только_ экзешником.
Напомню, что либы, бывают не только динамические aka DLL, но и статические и вообще либы исходников. Именно о последнем случае и идет речь. Так что разные exe => разные либы Graphics32 |
|
|
|
|
Приаттачил SASPlanet_SpinLock.rar для игр.
Кое-где вправил критическим секциям спинлоки (по идее должно зарулить для многопроцессорных тачек, правда только если не мало спинлоков накатил).
Кое-где поудалял. Примитивы переписал - чтобы их тоже можно было измерять.
Исправил ещё один найденный косяк в TUiTileDownload.RetartDownloadIfNeed. |
|
|
|
(0006098)
|
|
zed
|
|
14-03-2012 12:14
|
|
>Приаттачил SASPlanet_SpinLock.rar для игр
Наблюдаются проблемы с закрытием программы. Выход возможен только по 3-м кнопкам.
А так, работает нормально, но и жутких тормозов с 20-ти секундной перерисовкой у меня до этого никогда небыло. |
|
|
|
(0006099)
|
|
vasketsov
|
14-03-2012 12:27
(edited on: 14-03-2012 15:28) |
|
>Выход возможен только по 3-м кнопкам
Сделал отладку критических секций и нашёл дедлок.
Устранил. Приаттачил SASPlanet_Ok.rar.
|
|
|
|
|
>Выход возможен только по 3-м кнопкам
Подтверждаю.
Вроде бы визуально быстрее стало работать. Сейчас в Белоруссию скатаюсь, репортов понапишу. |
|
|
|
(0006102)
|
|
vasketsov
|
14-03-2012 15:47
(edited on: 14-03-2012 17:00) |
|
/TMapGPSLayer/BgDraw 3 0,90899197 00:02.727
Гы. Трижды по секунде уело ((
Добавил счётчики для слоёв gps и wiki (хотя тут и так понятно что всё жрёт Alayer.LoadTile в AddElementsFromMap). Приаттачил SASPlanet_NewCounters.rar
|
|
|
|
(0006115)
|
|
Tolik
|
|
15-03-2012 10:31
|
|
> Напомню, что (в моем случае) релиз от ночнушки отличался _только_ экзешником.
Это всё-таки некорректно. В ночнушке, вообще говоря, другие dll (и много отличий в ini). Хотя и не еррорит, но может быть, работает неправильно (дико тормозит).
Так что надо распаковать полную ночнушку в новую директорию и экспериментировать на ней. |
|
|
|
(0006116)
|
|
vasketsov
|
15-03-2012 16:21
(edited on: 15-03-2012 16:26) |
|
Основную часть залил и погонял. Вроде косяков нет.
Ешё по плану:
1. Добавить счётчиков производительности (внутри /TMapGPSLayer/BgDraw).
Ешё по плану сделать возможность настройки в ini:
2. Приоритетов потоков.
3. Используемых примитивов синхронизации (может потребоваться для компов с маленьким объёмом памяти, пока что неактуально).
4. Используемого количества спинлоков (для многопроцессорных тачек, пока что неактуально).
|
|
|
|
(0006117)
|
|
zed
|
|
15-03-2012 17:03
|
|
>Добавить счётчиков производительности
Кстати, может стоит все эти счётчики обернуть в директиву {$IFDEF DEBUG}? А то в релизе, они хоть и не отображаются в гуе, но все также продолжают вызываться. |
|
|
|
|
>обернуть в директиву {$IFDEF DEBUG}?
Сделаю чтобы QueryPerformanceCounter не звался, и на старте операции вылетал всегда 0. Счётчики будут вечно молодыми )) |
|
|
|
|
|
А еще лучше сделать FackedCounter, который будет в одном экземпляре, будет всегда возвращать на старте ноль, а при окончании просто ничего не делать. Так еще на памяти сэконмим. |
|
|
|
(0006125)
|
|
vasketsov
|
15-03-2012 21:24
(edited on: 15-03-2012 21:25) |
|
>FackedCounter
Сделал фэйковый List. Возвращает либо себя либо один "пустой" счётчик.
В принципе теперь можно даже отвязаться от DEBUG\RELEASE и в ini-шке сделать признак, работать со счётчиками или нет. Без счётчиков визуально быстрее.
А теперь внимание, очередной вопрос знатокам от телезрителей.
Если включён гугл - всё летает, добавляем НЯК - заметно торможение.
Походу наложение НЯК сушественно тормозит красоту. Характерные значения счётчиков (гугл и гугл+няк, по 5 раз дёрнул карту вправо и влево, в обоих случаях всё уже в памяти даже до первого раза):
/TMapMainLayer/BgDraw 10 0.02443674 00:00.244
/TMapMainLayer/BgDraw 10 0.10302740 00:01.030
Во втором слуачае из больших значений ещё:
/ClearStrategy/MoveImageClear 40 0.00939970 00:00.376
/ViewState/PosChange 10 0.06301723 00:00.630
Диагноз?
|
|
|
|
(0006126)
|
|
vdemidov
|
15-03-2012 21:53
(edited on: 15-03-2012 21:56) |
|
А что тут удивительного. Копирование участка картинки гораздо более дешевая операция, чем сборка попиксельная с учетом прозрачностей.
>Сделал фэйковый List. Возвращает либо себя либо один "пустой" счётчик.
Лучше не один пустой счетчик, а всегда себя и в нем же реализовать методы интерфейса-счетчика. И тогда смело можно выбрасывать условную компиляцию.
А еще нужно сделать версию счетчиков с подсчетом 10 максимальных значений. А то среднее время не очень показательно, если есть отдельные долгие операции.
|
|
|
|
|
Ээээ. Мммм. А раньше (в релизе) она была намного дешевле?
Я конечно понимаю что компоненты поменялись. Но сама по себе сложность операции-то технически не изменилась?
Хотя может там ваще такого не было, не помню уже... |
|
|
|
|
А кто сказал, что в релизе этой разницы не было?
Но вообще слои нужно полностью переделывать. Я это заню. Нужно держать не одну большую битмапку, а набор тайлов и по запросу отрисовывать их. |
|
|
|
|
вопрос ещё и в том, что на гибриде гугла ситуация несколько другая:
просто гугл
/TMapMainLayer/BgDraw 10 0.03011278 00:00.301
гугл + гибрид гугла
/TMapMainLayer/BgDraw 10 0.06380991 00:00.638
/ViewState/PosChange 10 0.06094623 00:00.609
/ClearStrategy/MoveImageClear 40 0.00946760 00:00.379
то есть как бы разница в 1.7 раза на тех же значениях PosChange и MoveImageClear. Не может не исключительно геоконвертер так гадить. |
|
|
|
|
|
А. Так яндекс еще ж и проекция другая. Там же рескейлинг идет. |
|
|
|
|
|
Тьфу, не 1.7, а (01.030-00.244)/(00.638-00.301) = 2.3 раза (разница в слоях) |
|
|
|
|
|
Я ж говорю там перепроецирование идет, то есть для получения одного тайла ресайзятся два оригинальных. |
|
|
|
|
|
И еще ты зря в куче мест в качестве синхронизаторов сделал MRSW. Он эффективен только при долгих операциях или при очень сильной конкуренции, а при слабой конкуренции выгоднее обычная критическая секция или даже простой спинлок. Тоесть нужно ввести еще одну функцию создани, которая будет созадвать синхронизаторы для быстрых операций и использовать ее в тех местах где раньше были критические секции. |
|
|
|
(0006141)
|
|
vasketsov
|
15-03-2012 22:49
(edited on: 15-03-2012 23:24) |
|
>зря в куче мест в качестве синхронизаторов сделал MRSW
А я как раз сделал, чтобы можно было легко поменять одним движением левой руки на критическую секцию со спинлоками ))). Идея изначально была в том, что там где нужен MRSW - его прямо и создавать, а функция чтобы могла и то и другое вернуть в зависимости от настроек. Ибо для отладки MRSW есть встроенная цаца, и его нам отлаживать просто незачем.
Так что по идее надо только высунуть наружу опцию, чего именно взвращать из соответствующей функции.
Или я вопрос в претензии неверно понял?
зы. Вообще для "микроблокировок" можно заюзать
InitializeSRWLock
AcquireSRWLockExclusive
...
тут описание с подробностями.
http://msdn.microsoft.com/ru-ru/magazine/cc163405.aspx
(для XP кстати тоже есть аналог)
|
|
|
|
|
Уухх, сколько всего накреативили.... :)
Господа, так со стороны юзера какие телодвижения _еще_ надо сделать? Что-то потестить (что?), куда-то посмотреть (куда?), что-то попробовать подкрутить (где?)
Или просто сидеть и не высовываться если проблема уже локализована(?) - и ждать фикса? |
|
|
|
(0006144)
|
|
Tolik
|
|
16-03-2012 04:11
|
|
> со стороны юзера какие телодвижения _еще_ надо сделать?
Я хоть и тоже юзверь, но повторюсь, надо проверить работу на чистой ночнушке, без к-л файлов из древнего релиза (только карты и кэш можно подсунуть старые). |
|
|
|
|
>надо проверить работу на чистой ночнушке
Не вопрос. Вечером проверим.
Только дайте кто-нить ради Кришны ночнушку в _нормальном_ архиве а? Ну ломает меня пол-системы обновлять (и потом чинить отвалившееся) ради факта одной тестовой распаковки... :(
Можно мылом на [email protected] |
|
|
|
|
>Или я вопрос в претензии неверно понял?
Неверно. Просто блокировки из TConfidDataElementBase принципиально отличаются от блокировок используемых при чтении-записи одиночных переменных. А создаются одной и той же функцией MakeSyncMulti. Соответсвенно, нельзя простыми методами заставить его пользовать MREW для длинных и спинлок для коротких блокировок. |
|
|
|
|
> Или просто сидеть и не высовываться если проблема уже локализована(?) - и ждать фикса?
Не. Все что здесь обсуждается к твоим проблемам отношения не имеет никакого. Проверить конечно нужно, но у тебя затык совсем в другом месте. |
|
|
|
|
>нельзя простыми методами заставить его пользовать MREW для длинных и спинлок для коротких блокировок
На самом деле конечно можно. По передаваемому классу (через Self). Но это краний случай.
То есть раскидываем MakeSyncMulti в 2 варианта и в TConfidDataElementBase делаем руками MREW, а для большинства остальных делаем Lightweight-аналог MREW?
Вообще походу надо написать некую фабрику классов, чтобы она выдавала IReadWriteSync в зависимости от запроса класса приложения. Там только системных аналогов MREW 2 штуки есть в зависимости от версии WinNT и от требования (просто быстрый read-write или более сложный с секцией и семафором). |
|
|
|
|
>у тебя затык совсем в другом месте
Ты вроде как ругался на то что у него PosChange большой.
Так вот в примере гугл+слой он тоже сравнивается с /TMapMainLayer/BgDraw.
Так что может эта проблема и есть (наложение слоёв медленное). |
|
|
|
(0006159)
|
|
Tolik
|
|
16-03-2012 08:33
|
|
> Только дайте кто-нить ради Кришны ночнушку в _нормальном_ архиве а?
Я, конечно, не верю, что это прям ТАК трудно - установить 7zip.
Ну уж так и быть, запаковал в самый ортодоксальный формат: http://narod.ru/disk/43849317001.bc02963e42f60a8d8a5dcc77da35ed57/SAS.Planet.Nightly.120316.5228.tgz.html |
|
|
|
|
Забыл совсем написать про настройку приоритетов. В ini-шке пример:
[ThreadPriorityByClass]
TMapMainLayer=3
TMiniMapLayer=1
[SleepByClass]
GUISyncronizedTimer=300
TGarbageCollectorThread=3000
Под ThreadPriorityByClass указываются конкретные классы (доступно для слоёв + для скачки по одному тайлу пальцем). Номинально приоритеты соответствуют ряду (tpIdle, tpLowest, tpLower, tpNormal, tpHigher), то бишь значения от 0 до 4. Если нет или кривое значение - берётся tpLower (оно = 2).
Внутри SleepByClass таймеры. Только 2 указанных здесь варианта. Значения по умолчанию 500 и 1000 соответственно. |
|
|
|
|
>По передаваемому классу (через Self). Но это краний случай.
Я ж написал "простыми методами"
>Вообще походу надо написать некую фабрику классов, чтобы она выдавала IReadWriteSync в зависимости от запроса класса приложения.
А как быть если в одном классе нужно 2 разных типа блокировок? Нет. Уж лучше пару фабричных функций для разных типов использования, а уже внутри функций пусть нужный примитив выбирается. |
|
|
|
|
>Я, конечно, не верю, что это прям ТАК трудно
Вi скорее всего просто ни разу не видели DEP HELL, когда после установки чего-нибудь ненавязчивого но лезущего в системные либы (а этот долбаный 7зип как раз туда и лезет, да еще и рута хочет при установке) - отваливается половина системы, прекрасно работавшей до этого. Зато 7зип заработает, да, и даст распаковать САСа (который потом не запустится по причине отваленных Иксов к примеру). В гробу бы я видал потом вправлять рабочую систему обратно, а работа будет тем временем немножечко постоять - я сегодня хочу отдохнуть после трудовой недели, а не иметь секс на скорость и прохождение... :)
http://en.wikipedia.org/wiki/Dependency_hell
Предыдущие-то тестовые сборки вона выше в шапке - в нормальном архиве, прекрасно открываются и БЕЗ ненужных дополнительных телодвижений и вопросов ни разу не создавали.
>запаковал в самый ортодоксальный формат
Вот пасиба. Вечером будем попробовать. |
|
|
|
|
>если в одном классе нужно 2 разных типа блокировок?
Ну я и имею в виду что класс типа Downloader-а попросит типа дай-ка мне одну легковесную RW (типа на статистику), одну нормальую RW (нюхать изменение системных сетевых настроек), а ещё впридачу одну CS на качалку. А не только по вызвавшему классу определять. И будет "внутри функций пусть нужный примитив выбирается". |
|
|
|
(0006166)
|
|
Tolik
|
|
16-03-2012 09:45
|
|
> Вi скорее всего просто ни разу не видели DEP HELL
Да видел, но всё равно же САС запускать через wine, можно там же и total с плагином развернуть.
Ну да ладно, не будем тему засорять, и так она уже вышла в рекордсмены по числу комментов. |
|
|
|
|
Наделал generic-функций и объектов для RW-синхронизации над системными функциями ntdll.dll (Resource и SRWLock). Если надо - добавляем свои, эти больше для примера наделаны и пока никуда не прикручены.
Если SRWLock (Vista и выше) будет рулить для простых нерекурсивных микроблокировок RW - попробую сделать аналог для XP на базе объекта ядра KeyedEvent (SRWLock на нём и работает, просто надо будет найти время и посидеть). |
|
|
|
|
ИМХО ты перестарался. Я предлагал добавить одну или две функцию.
Тоесть в модуле u_Synchronizer должны быть:
MakeSyncRWLight
MakeSyncRWShort
MakeSyncRWLong
MakeSyncRWHuge
И все. Внутри них выбирается нужный класс и создается объект синхронизации.
Все конкретные реализации вынесены вообще в отдельный модуль который юзается только в разделе реализации модуля u_Synchronizer. |
|
|
|
(0006171)
|
|
vasketsov
|
16-03-2012 13:12
(edited on: 16-03-2012 13:13) |
|
>И все
Да ради бога. Ведь "лишние" ж есть-пить не просят.
Наружу после удаления deprecated только они и будут торчать.
А фабрика просто однажды инициализируется, а потом только знает, чего доступно, а чего нет, и информацию для инициализации объектов выдаёт.
И вообще это были лишь примеры. Надо будет идти по коду и смотреть особенности факктически требуемой блокировки. В зависимости от этого и наделать нужных функций.
|
|
|
|
(0006175)
|
|
zed
|
|
16-03-2012 15:03
|
|
>Забыл совсем написать про настройку приоритетов.
Ё-маё, это ж просто сказка! Прописал в инишнике:
[ThreadPriorityByClass]
TMapMainLayer=4
TMapLayerWiki=4
[SleepByClass]
GUISyncronizedTimer=100
TGarbageCollectorThread=1000
и САС прям ожил :) Предлагаю сделать дефолтное значение TMapMainLayer=3 (как минимум) - никаких отрицательных моментов не замечено, только положительные. |
|
|
|
(0006176)
|
|
Tolik
|
|
17-03-2012 16:14
|
|
И правда, эти параметры помогают.
Создал страницу в вики для описания некоторых полезных ini: http://sasgis.org/wikisasiya/doku.php/%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_sasplanet.ini
Просьба скорректировать описание: что, собственно, за приоритеты, в чём измеряются таймеры, какие конкретно существуют классы, кроме перечисленных. |
|
|
|
(0006177)
|
|
zed
|
|
17-03-2012 19:35
|
|
>Просьба скорректировать описание
Да вроде всё верно написано.
>что, собственно, за приоритеты
Итак, что же такое приоритет? Приоритет - это величина, определяющая, насколько данный процесс должен выполнятся быстрее по сравнению с другими. Т.е., другими словами, чем выше приоритет процесса, тем больше времени он отбирает у системы и других, параллельно работающих процессов. Далее разберем возможные значения свойства Priority класса TThread в порядке возрастания приоритета:
tpIdle - процесс выполняется только тогда, когда система не занята и больше нет работающих в данных момент процессов;
tpLowest - на два пункта ниже нормального;
tpLower - на один пункт ниже нормального;
tpNormal - нормальный. Такой приоритет у большинства задач;
tpHigher - на один пункт выше нормального;
tpHighest - на два пункта выше нормального;
tpTimeCritical - самый высокий приоритет - занимает все время процессора и системы. Это приоритет для систем реального времени, для которых важна каждая секунда и даже малейшая задержка может привести к сбою. Будьте осторожны с этим приоритетом!
>в чём измеряются таймеры
Таймеры измеряются в миллисекундах ( 1 с. = 1000 мс. ).
>какие конкретно существуют классы
Список классов, для которых вынесены настройки приоритетов:
TMapGPSLayer
TWikiLayer
TMapMainLayer
TMapMarksLayer
TMiniMapLayer
TTileDownloaderUIOneTile |
|
|
|
|
zed, благодарю ))
Уточню ещё вот что, если вдруг это неочевидно:
tpIdle = 0
tpLowest = 1
...
tpHigher = 4
ставить приоритет выше этого в ini-шке не позволено. |
|
|
|
(0006179)
|
|
vdemidov
|
17-03-2012 22:34
(edited on: 17-03-2012 22:46) |
|
Еще одно замечание. Я скорее всего распихаю приоритеты по секциям настроек слоев, без всяких имен классов и добавлю возможность в рантайме менять их.
|
|
|
|
|
>по секциям настроек слоев
Хм. Идея как раз была чтобы любой поток (а не только слои, и при создании новых подхватывалось чтобы) можно было "покрутить", в том числе:
а) TTileDownloaderUIOneTile и получение доступных снимков.
б) удаление тайлов и генерация вышележащих.
в) экспорты.
Потому что когда вот прямо сейчас надо что-то быстро сделать - ждать остального совсем не имеет никакого смысла. Пусть даже тыкнуться в "окошко потока" и сменить приоритет без сохранения в ini только до конца его работы. |
|
|
|
|
> а) TTileDownloaderUIOneTile и получение доступных снимков.
> б) удаление тайлов и генерация вышележащих.
> в) экспорты.
Что мешает для этих задач иметь отдельные конфиги? Наоборот при наличии конфгов можно менять приоритет даже отдельной задачи из однотипных реализованных одним классом. |
|
|
|
|
>при наличии конфгов можно менять приоритет даже отдельной задачи
Можно "менять приоритет даже отдельной задачи" независимо от того, куда отнести данные по приоритетам, к общим настройкам сущности или к отдельной группе настроек приоритетов, таймеров и прочей аналогичной по сути ерунды.
Суть-то в другом. Как минимум - в операции сброса настроек на значения по умолчанию. При кривой настройке приоритетов или при изменении их обработки в ini операция сброса выглядит куда тривиальнее (для ручного выполнения), если надо просто секцию грохнуть. И сказать (и исполнить) юзеру "дай-ка погляжу эту секцию в ini" тоже куда проще, чем "все параметры с именем ThreadPriority в студию".
В общем-то я даже не представляю логику отнесения параметров настройки приоритетов в рамках настраиваемых сущностей. Ибо приоритеты их к самим сущностям никакого отношения не имеют и на работу их никак не влияют, а являются исключительно настройками их диспетчеризации. Идея как раз была все настройки диспетчера потоков и аналогичные вынести именно туда где они и нужны - отдельно для диспетчера. А не раскидывать по коду. |
|
|
|
|
>запаковал в самый ортодоксальный формат: http://narod.ru/disk/43849317001.bc02963e42f60a8d8a5dcc77da35ed57/SAS.Planet.Nightly.120316.5228.tgz.html [^]
Докладуюсь:
1. Скачал.
2. Распаковал в отдельную папку.
3. Перенес из старого саса: инишник, папку MAPS, папку CACHE, метки.
4. Запустил. Работает.
ИЗМЕНЕНИЙ В СКОРОСТИ ПО СРАВНЕНИЮ С ПРЕДЫДУЩЕЙ ВЕРСИЕЙ НЕ ВЫЯВЛЕНО.
+ к этому, новая версия обнулила файлы меток - за что ей отдельное спасибо. Хорошо хоть бэкапы остались.
>Забыл совсем написать про настройку приоритетов. В ini-шке пример:
Докинул в инишник к предыдущему пункту.
Стало много быстрее - ориентировочно раза в 2-3. Но все еще не так, как оно в релизе - я все еще вижу отрисовку тайлов глазками. Но уже много, МНОГО лучше.
Может есть смысл сперва отрисовывать в буфер, а потом выдавать юзеру готовый скрин? |
|
|
|
|
|
|
|
|
|
Та я слегка занят в последнее время. Нужно тебе будет подготовить релиз, в котором отключено будет все лишнее и включен новый способ отрисовки тайлов карт. |
|
|
|
|
>Нужно тебе будет подготовить релиз, в котором отключено будет все лишнее и включен новый способ отрисовки тайлов карт.
...еще подождем.....
PS: и релиз бы не для меня лично - а с убранной ошибкой _для всех_.
Для себя _лично_ - я кэш и так наработаю, и открою его старой версией на отличненько... :) |
|
|
|
|
>...еще подождем.....
....и еще месяц прошел......еще подождем.
PS: в последней ночнушке - без изменений. Точно так же печально отрисовываются тайлы. Заметил, что при ЛЮБОМ сдвиге экрана - он обновляется на "раз-два-три" (3 сек): сперва отрисовывается треть нужной области (независимо от ее формы), потом некая задумчивость на секунду, отрисовывается вторая треть, задумчивость, отрисовывается оставшийся кусок. Видно глазками, что отрисовывается по спирали от центра экрана и по час.стрелке.
Если сдвиг экрана значителен (90-95%) - то отрисовывается уже на 1-2-3-4. Всё это видно глазом в каждый момент времени и прекрасно повторяемо на моей стороне. :( |
|
|
|
|
Попробуй в ini-шники в разделе View добавить:
UseNewMainLayer=1
И не забудь приаттачить сюда инфу со счетчиков. |
|
|
|
(0007564)
|
|
Parasite
|
20-06-2012 16:44
(edited on: 20-06-2012 16:47) |
|
>И не забудь приаттачить сюда инфу со счетчиков.
Вставил UseNewMainLayer.
Ничего (визуально) не изменилось.
Карта + 1 слой + миникарта. Меток нет, GPS нет, отображения заполнения\анимации\"брать с других слоев"\"плавная прокрутка" - нет.
----------
/ClearStrategy/ZoomChangeClear 8 0,86622580 0,36959234 0,00905609 00:02.957
/ViewState/PosChange 38 1,95312890 0,16926373 0,00000542 00:12.632
/TMapMainLayerNew/BgDraw 1964 1,23678299 0,14987730 0,00003273 00:25.307
/TMapLayerGrids/Redraw 37 0,47163096 0,02920099 0,01597867 00:01.080
----------
Всё остальное - сильно меньше.
Заметил, что /TMapMainLayerNew/BgDraw + /TMapMainLayerNew/OnPaint + /TMapMainLayerNew/OneTilePaint постоянно увеличиваются примерно 2 раза в секунду, даже если никто ничего в сасе не делает.
PS: может ли это быть как-то завязанным на разрешение экрана? Монитор большой, разрешение 2560х1980 - и при сдвиге карты возможно приходится перерисовывать весьма большую кучу тайлов...? Правда это токи не объясняет того, почему на старых версиях все ОК на том же экране.
|
|
|
|
|
|
Отключи все сетки. Они очень круто тормозят все своим наличием. |
|
|
|
(0007567)
|
|
zed
|
|
20-06-2012 17:31
|
|
>Вставил UseNewMainLayer.
У меня от этого наоборот лаги идут - тайлы не перерисовываются после загрузки, пока мышом не встряхнёшь. |
|
|
|
|
>Отключи все сетки. Они очень круто тормозят все своим наличием.
Сетка есть, да. И шкала по центру экрана - тоже есть.
Вечером отключу, проверю.
PS: А почему в старых версиях - сетка не тормозит? :)
>У меня от этого наоборот лаги идут - тайлы не перерисовываются после загрузки
В моем случае - все тайлы уже не винте, для чистоты проверки скорости. Загрузку вообще не тестировал. |
|
|
|
|
|
Я просил приаттачить сюда всю инфу со счетчиков, а не 4 строчки. И еще полную инфу о процессоре, видеокарте и операционке. |
|
|
|
|
>Я просил приаттачить сюда всю инфу со счетчиков
Слова "все" там не было, и раньше по тексту тикета хватало только максимальных.
Приаттачу седня. UseNewMainLayer убрать, или пускай будет прописан?
>И еще полную инфу о процессоре, видеокарте и операционке.
Xeon L3014 2.4Ghz (x8 шт)
мамка SuperMicro RapidServer
32Gb RAM (винда32 видит не более 3х с гаком)
видео ATi Radeon X1950XT-X
разрешение экрана - 2560\1980
Операционка (на момент тестирования) - 2k3Serv R2 либо XPSP3, поведение САСа в обоих приблизительно одинаковое +\-
Диск - рамдрайв на 1Гб сугубо на время тестирования, кэш+сас+своп винды лежат на нем. |
|
|
|
|
UseNewMainLayer пускай будет. Новый слой конечно еще нужно допиливать, но тестить старый слой бессмысленно, он отправится на свалку истории в любом случае.
Ох чуствую дело тут в железе. Точнее в каких-то оптимизациях, которые есть в Gr32 и которые на твоей машине просто не пашут, точнее пашут, но замедляя, а не ускоряя. |
|
|
|
|
|
И еще. Запиши таки видео того что у тебя на экране происходит. |
|
|
|
(0007579)
|
|
Parasite
|
21-06-2012 08:22
(edited on: 21-06-2012 10:10) |
|
>в каких-то оптимизациях, которые есть в Gr32 и которые на твоей машине просто не пашут, точнее пашут, но замедляя, а не ускоряя.
Переход на этот GR32 когда был?
Ориентировочно, глюк начался в версиях где-то октября\ноября того года, и к январю достал совсем (отсюда и тикет). В релизе (апрель того года) глюка нет. Если примерно сходится с моментом перехода на GR32 - то скорее всего оно и есть.
Возможно, ей рвет крышу от тру мультипроцессорности (НЕ мульти-core) - оно не одно такое, нек.образом. Есть еще несколько софтин, работающих на одном мультикорном камне - и начинающих резко тупить уже при 2х сингл-корных и выше ровно на той же мамке. Связано с туплением программ на тему прерываний при обращении к разным потокам - генерируют кучу совершенно ненужных WaitState, и по идее должны решаться патчами от авторов - но авторы давно забили на эти проекты.
Также можно попробовать тот же САС на древнем ноуте - но там железо совершенно другое, и даже ЕСЛИ там заработает как надо, то причины тупизны на ЭТОМ - не подскажет. А работаю-то я как раз на этом...
Можно ли как-то запретить этот GR32 и вкорячить старое состояние дел (как оно было в релизе)? Сугубо тестовая версия с минимальным функционалом но без GR32 а с тем что там было до него. Или это слишком дофига откатывать придется?
|
|
|
|
|
|
http://blog.synopse.info/post/2010/07/15/Delphi-doesn-t-like-multi-core-CPUs-%28or-the-contrary%29 |
|
|
|
|
|
Если это правда, то у меня плохие новости для тебя. Увы. |
|
|
|
(0007582)
|
|
Tolik
|
|
21-06-2012 09:23
|
|
|
А можно запустить какую-нибудь виртуальную машинку, кот. работает ровно на одном процессоре? |
|
|
|
|
Дак (опять, в который раз) - почему релиз-то нормально работает вот прямо сейчас и на той же машине?
Когда перешли на Gr32? Меняли ли дельфу (компилятор) на промежутке с апреля по декабрь прошлого года? И если нет - то что из компонентов меняли за тот же период? |
|
|
|
|
|
Потому что с тех пор САС стал полностью многопоточным. В том релизе отрисовка карты шла из основного потока. Плюс с тех пор прибавилось разных тредов. И почти все взаимодействия тредов идут через Interlocked операции. |
|
|
|
|
|
Еще была смена версии Delphi на 2007, где по умолчанию стоит менеджером памяти FastMM |
|
|
|
|
|
Попробуй этот exe скомпиленный с другим менеджером памяти |
|
|
|
|
|
И еще один менеджер памяти |
|
|
|
(0007623)
|
|
Parasite
|
24-06-2012 11:09
(edited on: 24-06-2012 11:10) |
|
Докладуюсь.
>SASPlanet.TopMM.rar
Работает намного тормознее чем дефолтовый САС. Навскидку - раза в 2 печальнее. При этом если САС отрисовывает экран на 1-2-3сек (см.выше), то эта версия рисует 1-2, а последний третий шаг прорисовать вообще забывает. Так и висят пол-экрана пустыми. Передвигаешь экран - эта пустая часть отрисовывается, зато забывает отрисоваться уже другая. Короче - ффтопку.
>SASPlanet.ScaleMM.rar
Намного быстрее и дефолтового САСа, и даже предыдущего пункта. При достаточно больших значениях "кэшировать в память ХХХ тайлов" + "Х тайлов за границей экрана" - работает почти что терпимо. Но все равно заметно глазками, и с релизом - не сравнится. Имхо, этот вариант можно было бы сделать для саса дефолтовым даже....
Проблема одна - точно так же забывает прорисовать последнюю часть экрана пока не подвигаешь мышой, как и предыдущий пункт.
PS: еще имеется идея, что медленная перерисовка как-то связана со скоростью обновления экрана самим сасом. Когда сас просто стоит - /TMapMainLayerNew/BgDraw + /TMapMainLayerNew/OnPaint + /TMapMainLayerNew/OneTilePaint изменяются сами по себе раз в секунду где-то, если это рефреш экрана - то подозреваю, что и заметные глазом перерисовки 1-2-3-4 вызваны как раз этим рефрешем: отрисовали часть "в уме"-рефреш(отрисовка этой неполной части)-отрисовали еще часть "в уме"-рефреш, итд. Изменение тех счетчиков примерно раз-два в секунду просто весьма кореллирует со скоростью отрисовки всего экрана на 1-2-3-4, возможно от этого ноги и растут. Можно ли для теста изменить скорость этого рефреша, скажем, раз в 10 в любую сторону? :)
|
|
|
|
(0007624)
|
|
zed
|
24-06-2012 11:25
(edited on: 24-06-2012 11:27) |
|
Доступные таймеры:
[SleepByClass]
GUISyncronizedTimer=30
TGarbageCollectorThread=1000
А с приоритетами потоков не пробовал играться?
[ThreadPriorityByClass]
TMapGPSLayer=3
TWikiLayer=3
TMapMainLayer=3
TMapMarksLayer=3
TMiniMapLayer=3
TTileDownloaderUIOneTile=3
Описание тут: http://sasgis.org/wikisasiya/doku.php/%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5_sasplanet.ini
|
|
|
|
|
>Доступные таймеры:
>А с приоритетами потоков не пробовал играться?
О. Нет, не игрался ни с тем ни с другим.
Надо будет попробовать. Отпишусь. |
|
|
|
(0007626)
|
|
zed
|
|
24-06-2012 12:40
|
|
>забывает прорисовать последнюю часть экрана пока не подвигаешь мышой
Это из-за UseNewMainLayer=1 |
|
|
|
|
|
Запиши видео. Без видео я больше обсуждать ничего не буду. |
|
|
|
|
Попробовал на совершенно другом железе - старенький Целерон 1.8ГГц, 1 ядро, 512 рамы. Ничего не изменилось: релиз - летает, ночнушка - отрисовывает заметно глазу на 1-2-3-4, чем крайне и раздражает.
Вот видео поездок по карте (бинг+гуглгибрид): http://www.mediafire.com/?h7naw6o5q2p7m7p |
|
|
|
|
|
По результатам просмотра видео мое мнение такое: да слегка медленнее чем на любом из моих компов, но далеко не так критично, как ты тут описывал. Так что если крайне раздражает, то тебе не сюда, а к фармацевтам. |
|
|
|
|
Предлагаю оценку меры критичности оставить мне, и далее - не обсуждать.
То, где оно "слегка медленнее" - это просто выставленная дикая цифирка кэширования тайлов в память (на данный момент равная 500). Отсюда и рывки относительно быстрой отрисовки среди медленной и тягучей основной. На первых же секундах видео хорошо видно, когда САС только запущен и кэш в памяти практически пуст. Первые пару секунд так вообще ничего не происходит, несмотря на нажатую кнопку ZoomOut. Ближе к концу видео - немножко легчает если таскать по одному зуму, любой перезум на соседний - всё начинается сначала.
Впрочем, сугубо для сравнения могу сделать видео с релизом на той же машине. |
|
|
|
|
|
По мне и сейчас вполне нормально. Раз помогает кэширование в память, это значит что проблема или в считывании с винта, или в декодировании битмапок. Сама отрисовка вполне быстрая. Так что баг по поводу замедления "отрисовки" вполне можно закрывать. |
|
|
|
|
>По мне и сейчас вполне нормально.
Это по тебе. Возможно, ты привык к тормозам и общей задумчивости новомодных осей имени известно кого - я я привык к совокупной дури 8и серверных голов на условно-безразмерной памяти, и любое торможение чувствую ну вот прямо пальцами. На мое скромное имхо САС сейчас работает тормознее последнего фотошопа на том же железе (ибо тот у меня летает, а сас - нет).
И меня все еще интересует катастрофическое замедление работы двух версий одной и той же программы на одном и том же железе. Так что погоди закрывать - давай таки разберемся. Ну не просто ж так оно В РАЗЫ вылезло и стало тормозить, в конце-то концов. |
|
|
|
|
|
Тормозит оно точно так же как и раньше тормозило. Просто раньше ты этого не замечал из-за того что после того как ты отпустил мышку картинка не менялась до того момента как будет готово полностью новое изображение. А сейчас оно мгновенно отрисовывает то что может и отдает управление юзьверю. Тоесть даже при частично отрисованном экране, можно делать любые операции. |
|
|
|
|
|
Итого, мы разобрались, что сама отрисовка тайлов летает, а тормозит загрузка с диска. То ли чтение файлов, то ли раскодировка. Значит нужна информация счетчиков чтения с диска и декодеров картинок. |
|
|
|
|
|
И не забудь указать какая конкретно ночная сборка тестировалась. |
|
|
|
|
>Тормозит оно точно так же как и раньше тормозило. Просто раньше ты этого не замечал из-за того что после того как ты отпустил мышку картинка не менялась до того момента как будет готово полностью новое изображение.
Вознможно, спорить не буду. Но при том оно подготавливалось и выводилось за доли секунды, а ври новом раскладе - оно мало того что видно глазом, так еще и обработка занимает единицы секунд, и позволяет себе вообще пару секунд ничего не делать при нажатии на гуй.
>Тоесть даже при частично отрисованном экране, можно делать любые операции.
Если учесть то что предыдущий отрисовывался за долю секунды - то сомнительное достижение (там просто не было времени на доп.операции, даже если не было и возможности).
>мы разобрались, что сама отрисовка тайлов летает, а тормозит загрузка с диска.
не вижу из чего это следует. Во-первых это все лежит на рамдиске, во-вторых рамдиск свободен (коль скоро никто его больше не юзает - теста ради), а в-третьих еще и дикое число кэшируемых тайлов - тоже в силе ж.
Тормозит имхо что угодно, но не чтение.
>не забудь указать какая конкретно ночная сборка тестировалась.
12.6.14.5640, та же что и выше (та, что с разными манагерами памяти. Трабл +\- одинаков на всех трех - на штатной и на 2х других, что в аттаче в этому тикету). |
|
|
|
|
|
Данные встроенного профайлера забыл добавить. |
|
|
|
|
Только сейчас обратил внимание на эту фразу:
>Во-первых это все лежит на рамдиске
А убери ка ты этот рамдиск нафиг. Может в нем все и дело. И еще может дело быть в декодилке джипегов, она, кстати, пару дней назад менялась. Так что бери свежую ночнушку, отключай ремдрайв и начинай тестить. Для каждого теста сюда файл профайлера с комментариями о режиме запуска. |
|
|
|
|
>А убери ка ты этот рамдиск нафиг
А не меняется ничего, кроме дёргания винта. Пробовал уже, чай не дурак.
>файл профайлера
Это кто такой? |
|
|
|
|
>>файл профайлера
> Это кто такой?
Это то что выводится в окошке Debag Info. Вроде бы ты им уже пользовался. |
|
|
|
(0007859)
|
|
zed
|
|
24-07-2012 16:24
|
|
|
...и таки подкрути приоритеты потоков. |
|
|
|
(0007860)
|
|
zed
|
|
24-07-2012 16:37
|
|
Кстати, видео записано неправильно: должно быть видно полностью окно САС. Чтобы сразу было видно, какая версия САСа и было ли что загружено из интернета или всё берётся только из кэша.
И это, винда-то какая? Или ты может это под wine-ом тестируешь?
И для чистоты экспериментов нужно отключить кэширование тайлов в RAM (а не выставлять в 500) и отключить опцию "Брать тайлы из меньших масштабов" (если она включена) и все плюшки типа анимации и плавного перемещения. |
|
|
|
(0007869)
|
|
Parasite
|
25-07-2012 03:57
(edited on: 25-07-2012 04:05) |
|
>Это то что выводится в окошке Debag Info.
А. Ну так и говорил бы. Мы люди далекие от этих ваших современных жаргонизмов. :)
Я тогда попытаюсь выделить отдельную машинку (обычную, одноголовую, пользовательского\секретулькиного уровня) и поставить туда свежую винду ХП (или даже сабжевую) для чистоты тестов. Где-то у меня валялась ненужная мамка с попсявой коре3 или коре5...надо бы поискать да запустить.
Чтобы отвязаться от подозрений на конкретно мое рабочее железо, стало быть. Впрочем, тут и другие хомяки отметились с тем же багом, так что дело явно не в моем железе. Но для чистоты - пускай будет выделенная машинка. Все ж действительно хочу выловить этот гнусный достающий баг...
>...и таки подкрути приоритеты потоков
Крутил. Не помогло ни грамма, даже и отписываться сюда было нечем.
>Кстати, видео записано неправильно
Видео записано совершенно достаточно для иллюстрации описываемого бага. Полноэкранное писАть - у писАлки крышу рвет, нету такого формата у нее на 2560 точек по длинной грит, и скрэщивается. Да и не нужно оно - все запрошенные детали уже давно есть в теме, текстом.
>и было ли что загружено из интернета или всё берётся только из кэша.
Разумеется вся карта давно на винте, благо что ползаю я там по начальным зумам и прокачать их было - какие-то несколько килобайт. Да еще и по одним и тем же участкам езжу в видео - оно еще и в кэше собственно САСа должно быть, при такой-то цифирке кэширования. Ан нет - не помогает, как видишь.
>И это, винда-то какая?
В шапке указано.
>отключить опцию "Брать тайлы из меньших масштабов"
Не включена. Не пользуюсь.
>и все плюшки
Ну даже мне по видео заметно, что ничего такого не включено. :)
Кстати, при ползании по карте заметил еще одну непонятность: если я ползаю по новым регионам которых в кэше еще нет, + стоит режим "Инт+кэш" (то есть, подгрузка с интернета и покладание на диск = ON), то в рандомные промежутки времени на случайных тайлах в окне саса пишется какой-то длинный еррор, а на диск при этом кладется жпег нулевой длины, и так как он в кэше уже присутствует - то при повторном заходе он не перезапрашивается, всё так же ерроря длинной мессагой. Приходится чистить нулевые тайлы специально.
С проксика в сас при этом отдается нормальный тайл, ненулевой длины.
Не знаю, связано ли это с данным тикетом или это свежий баг - но в релизе такого не повторяется при тех же равных. Специально перепроверил. Возможно, связано с тем что сас одновременно пытается и записать, и прочитать один и тот же тайл при попытке его отображения\прорисовке окна.
Кстати, то же самое и при формировании вышележаших слоев: при гарантированном наличии всех тайлов нижнего слоя - верхние периодически генерятся с рандомными выпадениями тайлов, генерируя файлы нулевой длины и позднее ерроря на них длинной мессагой при попытке просмотра.
Я сейчас попробую выловить это и сделать скрин. Не знаю, но может иметь отношение и к моим общим тормозам при отрисовке, но что-то намекает мне что не все гладко либо с кэшированием либо с доступом к тайлам, и тогда может иметь отношение и к тормозной отрисовке... Если не имеет - скажите, закину новый тикет, ибо ручками чистить кэш - утомляет.
|
|
|
|
(0007870)
|
|
Parasite
|
25-07-2012 04:26
(edited on: 25-07-2012 04:27) |
|
>Я сейчас попробую выловить это и сделать скрин.
Готово. Скрин в шапке.
|
|
|
|
|
|
Нахрен он нам нужен. Этот баг уже давно вылечен. Пользуйся свежими ночнушками, а не старьем. |
|
|
|
|
|
Итого ты написал кучу текста и не сделал ничего о чем я просил. |
|
|
|
(0007873)
|
|
Parasite
|
25-07-2012 05:18
(edited on: 25-07-2012 05:19) |
|
>Пользуйся свежими ночнушками, а не старьем.
12.6.14.5640 - старье? Каждый день их качать что ли?
Кинься номерком тикета в котором оно описано\вылечилось, почитаю хоть.
>Итого ты написал кучу текста и не сделал ничего о чем я просил.
Ты читать умеешь? Попробуй сделать поиск по странице на "попытаюсь выделить отдельную машинку" и прочитать еще раз абзац, в котором оно найдется (а оно таки найдется). За прошедший час от момента написания - я не то что не попытался, а еще даже и до дома не доехал.
|
|
|
|
|
>12.6.14.5640 - старье? Каждый день их качать что ли?
Старье. Больше месяца прошло с тех пор. Хотя бы раз в неделю качать новую нужно.
За этот месяц там уже полтыщи изменений в репозитории и с полсотни багов исправленных. В частности баг 0001215 |
|
|
|
|
>В частности баг 0001215
Конкретно мой - 1352 (AV у меня нет), кой назначен\вылечен в еще не вышедшей 1208хх судя по шапке того тикета. Впрочем, тут этому обсуждению не место, ога.
Свежую ночнушку скачаю сегодня. |
|
|
|
(0007896)
|
|
zed
|
25-07-2012 18:49
(edited on: 25-07-2012 19:06) |
|
Для примеру, вот как оно работает у меня: http://www.mediafire.com/?j13niba3ch47z8s
P.S. UseNewMainLayer отключён, бо бажит.
|
|
|
|
|
>Для примеру, вот как оно работает у меня
Ты это...по карте бы там поездил туда-сюда хоть немного, а не только зум_ин\аут. На 16й секунде, слева экрана - вылазило что-то весьма похожее на то, о чем тут и речь (те самые видимые глазом заполнения тайлов поверх серого фона).
Подвигай карту туда-сюда на слое, причем желательно резко и с большим смещением, процентов на 95 экрана каждый раз (как у меня на видео например). Сабж проявится во всей своей красе.
А потом скачай релиз и сделай то же самое. Сабжа не будет и в помине.
PS: и у тебя работает примерно в 2 раза быстрее даже при перезуме, чем у меня. У меня сабж частенько вылазит и на перезуме тоже. |
|
|
|
(0007910)
|
|
zed
|
|
26-07-2012 05:56
|
|
>На 16й секунде, слева экрана
Это оно там из интернета чутка подгрузило. |
|
|
|
(0007911)
|
|
zed
|
|
26-07-2012 06:44
|
|
>Подвигай карту туда-сюда на слое
Да, действительно. На старой версии картинка отображается практически мгновенно, а на новой тупит. Но если в ini добавить:
[SleepByClass]
GUISyncronizedTimer=1
..то тормоза пропадают. Видно что картинка грузится не монолитом, как в прошлом релизе, но и не тормозит на отдельных тайлах.
|
|
|
|
(0007912)
|
|
zed
|
|
26-07-2012 06:55
|
|
Мда, а по дефолту этот таймер срабатывает через 500 мс. Т.е. можно ручками поставить 2000 (чтоб наверняка) и наблюдать картину маслом... т.е. получается тут архитектурная ошибка и нужно этот момент перепрограммировать, чтоб без всяких таймеров.
Кстати, скорость отрисовки одинаковая что с UseNewMainLayer, что без него. Но с ним глючит: если включён слой (гибрид), то могут появляться дыры в карте (забывает перерисовать тайл). Если же включена только карта, без слоёв, то всё ОК. |
|
|
|
|
>Это оно там из интернета чутка подгрузило.
Ну вот. А у меня оно так даже с рамдиска... :(
>Да, действительно. На старой версии картинка отображается практически мгновенно, а на новой тупит.
Именно это я и пытался сказать с самого начала.
>скорость отрисовки одинаковая что с UseNewMainLayer, что без него. Но с ним глючит: если включён слой (гибрид), то могут появляться дыры в карте (забывает перерисовать тайл).
Подтверждаю.
А про глюки этого уже упоминалось выше.
>[SleepByClass]
>GUISyncronizedTimer=1
>..то тормоза пропадают.
О. Надо будет попробовать вечерком.... А что это за параметр такой? |
|
|
|
(0007914)
|
|
zed
|
|
26-07-2012 07:50
|
|
Похоже, этот параметр отвечает за то, как часто будет перерисовываться карта. Соответственно, по дефолту карта перерисовывается 2 раза в секунду и при больших разрешениях монитора, оно за одну перерисовку не успевает отобразить все тайлы и ждёт целых 0,5 сек, чтобы начать отображать остальное...
Кстати, аналогичный параметр есть и у статусной строки:
[StatusBar]
MinRedrawTime=1
и если его значение выставить в 1, то циферки в статусе начнут очень быстро изменяться при движении мышом по карте, что создаёт визуальное впечатление очень быстрой работы САСа. |
|
|
|
|
|
Только что залил коммит, который убирает артефакты в новых тайловых слоях. Проверьте. |
|
|
|
|
>при больших разрешениях монитора, оно за одну перерисовку не успевает отобразить все тайлы и ждёт целых 0,5 сек, чтобы начать отображать остальное...
...а так как у меня заметна глазом перерисовка рывками на 1-2-3-4 - то соответственно это повторяется (у меня) аж 4 раза при обычной работе в окошечке, и больше - при разворачивании на полный экран...
Всё вроде сходится. Вечером буду пробовать. :)
Если сработает - то надо бы в новых версиях саса их как-то выставить дефолтовыми, что ли...
PS: а про первый таймер уже говорилось тобою выше, в свете приоритетов. Я соответственно пробовал только цифирки приоритетов (и они не дали никакого результата), а в таймеры как-то не залазил. Впрочем, там и не предлагалось скинуть их аж до единицы. |
|
|
|
(0007919)
|
|
zed
|
26-07-2012 08:36
(edited on: 26-07-2012 08:56) |
|
>Только что залил коммит, который убирает артефакты в новых тайловых слоях. Проверьте.
Помогло.
|
|
|
|
(0007920)
|
|
zed
|
|
26-07-2012 08:54
|
|
>Если сработает - то надо бы в новых версиях саса их как-то выставить дефолтовыми, что ли...
C таким значением таймера начинает лагать анимация при смене зума и движение по инерции. |
|
|
|
|
>C таким значением таймера начинает лагать анимация при смене зума и движение по инерции.
А я ими всё равно не пользуюсь.
Так какое безопасное значение предлагаешь, чтобы было "как в релизе"? |
|
|
|
(0007924)
|
|
zed
|
|
26-07-2012 09:14
|
|
|
При 50 лагов с анимацией не наблюдается, так что можно рекомендовать это значение как дефолтное. Но в идеале, конечно же, лучше изменить логику отрисовки и убрать привязку к таймеру. |
|
|
|
(0007925)
|
|
vdemidov
|
26-07-2012 09:20
(edited on: 26-07-2012 09:22) |
|
Как ты ее уберешь? Менять что-то в визуальных контролах можно только из основного потока. А картинка собирается в фоновых потоках. И основному треду еще действия пользователя и анимацию нужно обрабатывать.
ЗЫЖ Использовать синхронайзы не предлагай. Это костыль хуже таймера.
|
|
|
|
(0007926)
|
|
zed
|
|
26-07-2012 09:58
|
|
Ну, к примеру, дополнительно отправлять сообщения главному окну на перерисовку.
Аналогично, и отрисовку статусной строки повесить на OnMouseMove, чтоб таймер не выкручивать в ноль. При этом и таймер оставить, чтобы обновлялось когда мыша не трогаешь. |
|
|
|
|
Какие сообщения? 50 тайлов на экране. Битмапки+метки+векторые+GPS-трек+сетки итого после сдвига карты 250 сообщений за пару секунд?
Про мышь давай пока не будем.
И кроме мыши есть еще GPS маркер и куча всего другого. Так что без таймера все равно не получиться. |
|
|
|
(0007928)
|
|
zed
|
|
26-07-2012 10:30
|
|
>250 сообщений за пару секунд?
Да хоть 100500 - форма ж их тоже принимает с определённым интервалом, т.е. сообщения имеют свойство накапливаться (если это одно и то же сообщение). При горизонтальном движении мыша по экрану 1920*1080 pix, событие OnMouseMove будет срабатывать периодически и в итоге, чем быстрее мышь движется, тем меньше событий словит форма. Вот и тут можно что-то подобное замутить (в дополнение к таймеру). |
|
|
|
|
Докладую:
1. Поставил [SleepByClass]GUISyncronizedTimer=50. Визуально мало что изменилось - визуально стало чуть быстрее, раза эдак в 2-3. Но отрисовка все так же видна глазом, по спирали по часовой стрелке от центра, и до "как было в релизе" - еще далеко.
И если раньше оно отрисовывало целыми кусками экрана - то сейчас явно видно заполнение потайлово, они так и "вклеиваются" в короеда по одному.
2. Поставил [SleepByClass]GUISyncronizedTimer=1. Визуально - то же что и п.1.
Замечено, что сейчас при zoom_in\out сас вообще впадает в кому и пару секунд думает перед началом отрисовки.
3. Поставил [SleepByClass]GUISyncronizedTimer=5000 - и вот он, сабж в чистом виде. Подтормаживания на 5сек при перерисовке экрана, как раз теми кусками что я и наблюдал до этого.
4. Вписал UseNewMainLayer=1 во [VIEW]. Скорость не возросла, но глюки с потерей отображения тайлов - во всей красе (свежую ночнушку скачал только что). Убрал опять UseNewMainLayer от греха подальше.
Выводы: таки да, двигаемся в верном направлении - заметно явное влияние этой цифирки на быстродействие сабжа. Но до скорости релиза - надо бы еще попилить.
Оставил себе пока [SleepByClass]GUISyncronizedTimer=1. Все лучше, чем без него. |
|
|
|
(0007953)
|
|
zed
|
|
26-07-2012 19:47
|
|
>Замечено, что сейчас при zoom_in\out сас вообще впадает в кому и пару секунд думает перед началом отрисовки.
Да, но только при таймере = 1 и включённой анимации. Если таймер ставить на 50, то всё должно быть нормально.
>Вписал UseNewMainLayer=1 во [VIEW]. Скорость не возросла, но глюки с потерей отображения тайлов - во всей красе
Фикс бага прилетит только завтра. |
|
|
|
|
>Да, но только при таймере = 1 и включённой анимации.
Анимация НЕ включена. И я написал об лаге как раз в подпункте GUISyncronizedTimer=1. Просто нажимаем например "zoom+" - сас пару секунд в коме и ничего не делает (а-ля "висит"), потом РЕЗКО (без анимации) меняет экран на пустой серый с +1 зумом и соотв.сеткой, и начинает его заполнять по спирали (вклеивание тайлов заметно глазом).
Релиз же не подтормаживает и не заполняет столь медленно и тягуче, хоп - и готово, практически моментально.
>Если таймер ставить на 50, то всё должно быть нормально.
Уже несколько лучше чем было, и уже почти можно пользоваться - но до скорости релиза еще весьма далеко, вот в чем вопрос.
>И где они?
Да что ж ты такой нетерпеливый-то у нас все время, а...ты просил это всего-то ПОЗАВЧЕРА! Как только будет готово - так сразу и. Ждите.
Ну или поставь у себя GUISyncronizedTimer=2000 и пронаблюдай сабж во всей красе.
Вопрос: на текущем уровне развития САСа - скорость отрисовки "как у предыдущего релиза" вообще достижима, сугубо архитектурно? Та, где отрисовка отдельных тайлов НЕ ВИДНА глазом (пускай она сейчас работает по другому и не лочит саса, но чтобы это было БЫСТРО)? Если нет - то хоть затестись тут ночнушками, даже если они правильно заработают... |
|
|
|
(0008013)
|
|
zed
|
|
30-07-2012 08:17
|
|
|
"Программа работает настолько медленно, что если прислушаться, то можно услышать, как аргументы в функции превращаются в параметры." (с) баш |
|
|
|
|
>И где они?
На заданный 27.07 конкретный вопрос ответить уже неделю так и некому, как я понимаю? |
|
|
|
(0009565)
|
|
Tolik
|
|
16-10-2012 07:05
|
|
|
Вроде пошустрее стало? Видимо, в связи с 0001237? |
|
|
|
|
|
Да. Сейчас САС в принципе не держит больших битмапок на весь экран. Вся работа идет с отдельными тайлами. Соответственно при любых сдвигах карты нам не нужно ковырять многомегабайтную битмапку, а достаточно только поменять в матрице ссылки на конкретные тайлы и догрузить недостающие по краям. |
|
|
|
(0009622)
|
|
zed
|
|
20-10-2012 19:55
|
|
|
Кстати, у меня появляются жуткие лаги и тормоза с отрисовкой, если сменить дефолтный алгоритм растягивания изображений с Nearest на Box (может и на других так же - не проверял). |
|
|
|
(0009623)
|
|
Garl
|
|
20-10-2012 20:35
|
|
>если сменить дефолтный алгоритм растягивания изображений с Nearest на Box
аналогично. |
|
|
|
(0009626)
|
|
Tolik
|
|
21-10-2012 06:59
|
|
А уж Lanczos вообще иногда зависает во время Zoom Animation!
Это новый баг. |
|
|
|
(0009627)
|
|
Garl
|
|
21-10-2012 07:07
|
|
|
ИМХО по хорошему надо бы разделить конфиги алгоритма вывода на экран и дефолтные значения при генерации тайлов |
|
|
|
|
Сейчас сделаю. Там их штук 5 разных алгоритмов будет :)
1. Вывод непосредственно на экран (играет роль при анимации зума)
2. При смене зума получение чернового варианта тайлов из текущих отображаемых
3. Получение тайла слоя Z+1 из тайла слоя Z
4. Перепроецирование тайла.
5. Ресайз иконок меток
6. Дефолтное значение при генерации тайлов.
Может еще что-то забыл.
Хотя может и стоит на пункты 1 и 2 захардкодить Nearest |
|
|
|
(0009632)
|
|
Tolik
|
21-10-2012 11:40
(edited on: 21-10-2012 11:51) |
|
Открыл 0001643 по поводу ресайза.
А этот, наверно, можно закрыть?
Да, 1 можно захардкодить на Nearest, а 2 - не стоит, т.к. иногда черновой вариант остаётся единственным.
|
|
|
|
|
|
Проверь на завтрашней ночнушке и приложи, наконец, данные из Debug Info |
|
|
|
|
Поскольку топикстартер проверять последние сборки и предоставлять инфу с встроенного профайлера отказывается (моя последняя просьба проверить была 5 месяцев назад и ни ответа ни привета), а на всех доступных мне машинах начиная от нетбука на атоме и заканчивая рабочим Core i7-3770 все летает, то считаю багу полеченной.
PS: To Parasit, если таки захочешь продолжить обсуждение то начни с предоставления подробной инфы на заданные вопросы. |
|
|
|
|
>Поскольку топикстартер проверять последние сборки и предоставлять инфу с встроенного профайлера отказывается (моя последняя просьба проверить была 5 месяцев назад и ни ответа ни привета), а на всех доступных мне машинах начиная от нетбука на атоме и заканчивая рабочим Core i7-3770 все летает, то считаю багу полеченной.
Бага повторится у тебя при найденной zedом фиче. "Поставь у себя GUISyncronizedTimer=2000 и пронаблюдай сабж во всей красе". Эта проба была сделана? Каковы результаты попытки повторения сабжа?
Бага все там же, повторяется, не полечена. Так как скорость отрисовки люто не устраивает уже год - то давным-давно откатился на предыдущие версии, их и юзаю.
Заданный мною 4го августа прошлого года вопрос про саму сущность дальнейших проб - тоже остался без ответа без привета, а кучка дальнейшего обсуждения вообще было не со мной - и непонятно кому адресовался последний посыл потестить. Если это было адресовано мне - то потестю, отпишусь. Но вряд ли там будет что-то другое чем уже указанное выше - ибо визуально всё тормозит точно так же. |
|
|
|
(0010885)
|
|
vdemidov
|
15-03-2013 09:38
(edited on: 15-03-2013 09:49) |
|
> "Поставь у себя GUISyncronizedTimer=2000 и пронаблюдай сабж во всей красе"
Ну естественно если поставить обновление через 2 секунды, то задержка обновлений будет нехилая. А ты что хотел? Поставь 200 и наслаждайся.
PS: Очень похоже на вопрос на СТО: "А почему у меня машина так медленно едет, когда я ее на ручник ставлю".
|
|
|
|
(0010887)
|
|
Parasite
|
15-03-2013 09:53
(edited on: 15-03-2013 09:54) |
|
>Поставь 200 и наслаждайся.
Выше, практически год назад (пост 0006186) - уже тестировали с 300 (при дефолтных 500). Помогло, но до предыдущих версий все равно далеко. Дальнейшее уменьшение значения - прироста в скорости уже не дает, при этом предыдущий релиз всё равно работает заметно быстрее.
Куда еще понаслаждаться? :(
>PS: Очень похоже на вопрос на СТО: "А почему у меня машина так медленно едет, когда я ее на ручник ставлю".
Потому что некоторые уже не помнят, что мы ее с него сняли год назад - а она все равно еле плетется.
|
|
|
|
(0010888)
|
|
zed
|
|
15-03-2013 10:00
|
|
|
Теоретически, баг должен сойти на нет после реализации 0001466 т.е. этот GUISyncronizedTimer отомрёт как рудимент. |
|
|
|
|
>баг должен сойти на нет после реализации 0001466 т.е. этот GUISyncronizedTimer отомрёт как рудимент.
Настораживает то, что [у меня] даже при установкетаймера в самый минимум (на значения 5...10) - тормоза все равно остаются. Не такие как при дефолтных 500 - но все еще весьма заметные.
Если бы дело было ТОЛЬКО в этом таймере - по идее тормоза этого тикета сводились бы на нет, разве не так? |
|
|
|
|
|
Может проблемы в твое систем/винде/настройках саса (нужное подчеркнуть). Может вообще в твоем восприятии. Так что этот тикет будет закрыт до тех пор пока не будет видео на котором видно тормоза, плюс файла со счетчиками производительности для этого же запуска, плюс ini-шника, плюс sml файлов, плюс максимально полной информации о системе. Еще раз повторяю на всех моих конфигурациях скорость отображения при зумах и сдвигах карты адекватна производительности системы. То есть на атоме не сильно тормозит, на Core2Quad очень быстро работает, а на i7 просто летает. |
|
|
|
|
>пока не будет видео на котором видно тормоза, плюс файла со счетчиками производительности для этого же запуска, плюс ini-шника, плюс sml файлов, плюс максимально полной информации о системе.
Вдемидов, ну не морочь голову ради Христа хоть ты еще. Все запрошенное уже предоставлялось, уже рассматривалось и комментировалось тобою же и остальными присутствующими, вот например то же видео - в посте 0007844 выше было, конфиг системы - в 0007576, счетчики выше были аж несколько раз, итд. Сейчас что требуется? Перепостить то же самое сюда заново? Зачем?
Не заинтересован чинить - так и скажи, делов-то. Я ж совершенно не настаиваю и не принуждаю, да и забыл уже про этот тикет если бы сегодня в мыло твой наезд не свалился. В старых версиях оно всё прекрасно работает и без необходимости привлечения ноутбуков с Core7 - а новые фишки лично мне совершенно не нужны.
Только вот статус тикету надо будет поменять с "resolved" на "wont_fix", судя по всему. |
|
|
|
|
>Перепостить то же самое сюда заново? Зачем?
Конечно. Потому что это все было, во-первых, по отдельности, а во-вторых, почти год назад и устарело чуть больше чем полностью.
>Не заинтересован чинить - так и скажи, делов-то.
Конечно не заинтересован. С чего бы мне быть заинтересованным? У меня все работает быстро.
>Только вот статус тикету надо будет поменять с "resolved" на "wont_fix", судя по всему.
Только не "wont_fix", а "unable to reproduce" потому что у меня везде работает в десятки раз быстрее чем в упоминаемых тобой старых версиях. |
|
|
|
|
>почти год назад и устарело чуть больше чем полностью.
C моей стороны (визуально) ничего не изменилось. Как лагало - так и лагает, никакой хотя бы минимальной (определяемой визуально) подвижки нет.
Но всё в корне меняется, как только запускается САС двухгодичной давности (при прочих равных - инишник, карта в кэше, железо\ось).
>У меня все работает быстро.
На это у меня есть ответ "А у меня всё стало работать медленно". Тебе чем-то помогла эта фраза? Так и мне не помогает то, что у тебя - быстро. Я вообще не сторонник решать тормоза программы наращиванием тупой дури камня, и чтобы он это всё протягивал. Благо что САС - вовсе не та прога, где нужно дикое быстродействие и все операции (включая скроллинг по уже имеющемуся на диске кэшу) способны ТАК лагать, причем только в новых версиях.
>потому что у меня везде работает в десятки раз быстрее чем в упоминаемых тобой старых версиях.
Именно поэтому я и настаиваю на том, что сие есть баг который надо решать - а не закрывать. У меня он вполне себе reproduceable уже второй год, но никому это неинтересно.
Что еще от меня требуется, чтобы ты (или кто-то другой) взялись его решать по существу? Если нужно всё то же самое, но еще раз и свежее - то это займет какое-то время, и вряд ли будет как-то особо отличаться от предыдущего.
PS: а давай зайдем с другого бока? Дай мне свой инишник (в мыло) оттуда, где у тебя ничего не тормозит - и я попробую у себя? |
|
|
|
|
>На это у меня есть ответ "А у меня всё стало работать медленно". Тебе чем-то помогла эта фраза?
А зачем мне помогать? У меня все нормально. Я никому и ничего не должен. Это у тебя проблемы и я в свое свободное время могу захотеть помочь их решить.
>Что еще от меня требуется, чтобы ты (или кто-то другой) взялись его решать по существу? Если нужно всё то же самое, но еще раз и свежее - то это займет какое-то время, и вряд ли будет как-то особо отличаться от предыдущего.
Полного набора, не было ни разу. А еще хорошо бы проверить с чистым ini
> Дай мне свой инишник (в мыло) оттуда, где у тебя ничего не тормозит - и я попробую у себя?
Удали его вообще и дай сгенерить все параметры по-дефолту. |
|
|
|
|
>У меня все нормально.
У меня (на НЕ твоих версиях) тоже, а на твоих - нет.
>Это у тебя проблемы и я в свое свободное время могу захотеть помочь их решить.
Это проблемы у курируемой тобою по собственной инициативе программы, повторяющиеся\проверяемые и у меня тоже в том чисде. Готов внести посильную лепту в уничтожение оного конкретного. А именно свои проблемы я давно привык решать сам. :)
>еще хорошо бы проверить с чистым ini
>Удали его вообще и дай сгенерить все параметры по-дефолту.
Дичайше тормозит по сравнению с 10хххх, см. начало тикета. Тормозит в т.ч. и потому, что все таймеры выставлены не на нужные, а на дефолтовые значения. Основной тормоз - в отрисовке экрана после сдвига карты мышом, ЗАМЕТНО медленнее - и отрисовка каждого отдельного тайла заметна глазом. В старой версии, при прочих равных - летает. |
|
Clipboard01.jpg (64,587) 13-03-2012 14:28
startup (4,456) 14-03-2012 15:33