|
Notes |
|
|
(0000228)
|
|
vdemidov
|
24-09-2010 13:57
(edited on: 06-04-2011 23:41) |
|
Всем хочется, и мне в том числе. Будет одновременно с поддержкой плагинов.
|
|
|
|
(0000343)
|
|
Tikh
|
|
14-10-2010 08:00
|
|
|
Скажите, а когда примерно ждать поддержку плагинов? |
|
|
|
|
|
|
|
(0000395)
|
|
DJ VK
|
|
05-11-2010 05:36
|
|
Пожелание. прошу учесть. Не надо делать 2-3 базы данных очень большого размера. Прошу
1. разбить базу на среднего размера файлы. в файле 16k или 64k тайлов. Чтобы разбиение было по квадратам, а размер одного файла не превышал 1-1,2 ГБ. тогда легче обмениваться.
2. Организовать возможность раздельного хранения файлов баз - создается список путей, и при работе в автомате в соответствии с очередностью последовательно они заполняются, забив один диск (например задается квота свободного места. достигнута - переход к след папке) идем на другой. а пользователь может переносить при желании файлы баз между этими путями.
Когда будет мультизакачка слой за слоем автоматическое забивание дисков может и пригодиться.
3. Если квоты исчерпаны пользователь получает уведомление - некуда скачивать. |
|
|
|
(0001578)
|
|
gpsMax
|
|
06-04-2011 23:44
|
|
|
Насчёт медленного копирования - на форуме было подробное обсуждение данного вопроса. Лучшим обходным решением было признано создание контейнеров в TrueCrypt, но это именно временное обходное решение. Хотя, надо сказать, работает неплохо. |
|
|
|
(0002129)
|
|
Tikh
|
|
20-04-2011 10:26
|
|
|
Не поделитесь ссылочкой на форум, где обсуждают True Crypt? |
|
|
|
(0002143)
|
|
gpsMax
|
|
20-04-2011 12:01
|
|
http://sasgis.org/forum/viewtopic.php?f=3&t=540
Исходная тема, 12 страниц, но оно того стоит.
плюс
http://sasgis.org/forum/viewtopic.php?f=2&t=24&start=30 (немного про Truecrypt)
http://sasgis.org/forum/viewtopic.php?f=2&t=34
http://sasgis.org/forum/viewtopic.php?f=2&t=1092 |
|
|
|
|
|
Есть такая идея: сохранять кэш каждой карты в совершенно отдельную папку. Чтобы не только название папки NameInCache задавалось, но и полный путь. Это позволит, например, задать в том же TrueCrypt для каждого кэша отдельный контейнер. И обрабатывать содержимое кэша будет проще, так как файлы будут меньшего размера. |
|
|
|
|
|
|
|
|
|
Отсутствие многих знаний. Как я считаю, путь ко всему кэшу программы прописывается в настройках, и он един для всех карт. Различия только в названиях папок, но лежат-то они все в одной. Не догоняю чего-то я? |
|
|
|
|
|
В NameInCache вполне можно прописывать полный путь. Это первый вариант. Второй это монтирование дисков как папок. |
|
|
|
|
|
Надо попробовать по первому варианту. Второй не подходит мне, так как нужно обратное: смонтировать папки, точнее, файлы, как диски. |
|
|
|
(0002215)
|
|
gpsMax
|
21-04-2011 12:08
(edited on: 21-04-2011 12:09) |
|
> Второй это монтирование дисков как папок.
Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это. Положение могут спасти точки перехода NTFS (symbolic links вроде они называются), но не весь софт их поддерживает и данные с ними убить можно запросто.
А вот полный путь в NameInCache - это очень здорово, спасибо.
|
|
|
|
|
>Да, но тогда на этих подмонтированных дисках папки кэша будут в корне, неаккуратно это.
Если эти диски тома TrueCrypt отдельные для каждой карты, то вполне аккуратно. |
|
|
|
|
|
Я попробовал на одной карте работать с трукриптовским файлом-контейнером. Всё получилось, тормозов не заметно. Но есть один недостаток: мало букв в латинском алфавите, чтобы каждой карте присвоить свой диск. Придётся объединять несколько карт в один диск. Но главное - что можно будет этот диск-файл скинуть хоть на DVD, хоть на флешку и отнести куда-либо, не тратя время на упаковку-распаковку. |
|
|
|
(0002249)
|
|
gpsMax
|
22-04-2011 12:08
(edited on: 22-04-2011 12:11) |
|
Кстати говоря, не все контейнеры одинаково полезны. Я долго использовал майкрософтовский vhd способом, описанным на форуме. Но, во-первых, его затруднительно использовать под семёркой, нет родных дров под неё. И, во-вторых, чуть-чуть сыпятся данные, очень-очень редко, но, согласитесь неприятно видеть даже один битый тайл на сто тысяч - моя примерная оценка. В трукрипте потери данных не было замечено и работает он так же шустро, несмотря на лишнее шифрование. Я к тому, что при переходе на контейнер/БД нужно будет смотреть, как всё это заработает под нагрузкой, по скорости и надёжности.
|
|
|
|
(0002698)
|
|
gpsMax
|
|
26-05-2011 20:02
|
|
|
Ещё соображение: автор SAS4WinCE придумал и реализовал сжатый формат контейнера, что-то типа zip, но оптимизированного под тайлы. Если этот формат понравится, можно импортировать эту идею вплоть до кусков кода. |
|
|
|
|
|
Ну если кто-то покажет описание этого формата, а еще лучше исходники, то почему бы нет. Боюсь только у нас разные стратегии работы с кэшем. У него неизменный кэш, к которому идет только доступ на чтение, а у нас докачиваемый, генерируемый и тд контент. |
|
|
|
(0003092)
|
|
v_max
|
|
30-06-2011 05:35
|
|
Для кэша самой планеты врядли подойдет.. н еориентирован он на добавление
или удаление
А вот экспорт в него было-бы здорово сделать..
Я пытался с дельфями разобраться (как с инструментом и средой)
чтобы плагин написать... но не осилил ;(
Могу сорцы паковщика выложить .. писано на дотнете. |
|
|
|
(0004639)
|
|
zed
|
|
26-12-2011 18:48
|
|
Сделал новый тип кэша на базе BerkeleyDB.
Предварительно структура такая: <ZOOM>\<X/1024>\<X/256>.<Y/256>.db
Т.е. получается, что стандартные сасовские подпапки сохраняются в отдельные файлы БД, причём в каждой БД будет не более 65536 файлов (квадрат в 256*256 тайлов).
Поддерживаются все операции (чтение/запись/удаление), информация об отсутствующих тайлах (*.tne) сохраняется в отдельные БД с расширением *.tne вместо *.db (сортируются аналогично). |
|
|
|
|
>BerkeleyDB
А насколько тяжело будет сделать, чтобы работа с хранилищем тайлов была ТОЛЬКО через хранимые процедуры? Ну и соответственно через ODBC их гонять на любом серваке в локальной сети. |
|
|
|
(0004641)
|
|
zed
|
|
26-12-2011 19:16
|
|
Э.. я вообще не понимаю о чём ты :)
Про сеть могу сказать только, что эта БД разрешает многопользовательский доступ только в пределах системы, т.е. грубо говоря, несколько копий программы могут нормально работать с одним кэшем, а вот если кто-то начнёт ещё и по локалке в неё подгружать, то быть беде. |
|
|
|
|
Я про запись тайлов во "взрослые" СУБД типа oracle, mssql, sybase,...
Вот у меня например и так сервак Sybase ASE крутится - фигли ему "простаивать"?
А гигабитная локалка навряд ли сильно проиграет нжмд. А легко может даже и выиграть, всё же СУБД хранит и кэширует мелкие файлики лучше чем ФС. |
|
|
|
(0004646)
|
|
zed
|
|
26-12-2011 20:18
|
|
А, ну так никаких проблем. Нужно всего 5 функций: read, write, delete, exist и get_file_name (последняя чисто чтоб юзеру показать, какой конкретно тайл обрабатывается). И вперёд :)
Только, красивше, конечно, этот момент сделать плагином, а то и код замусорится да и exe-ха будет расти не по дням, а по часам (в случае с MySQL надо подключать компонент, который + пару Мб точно докинет, и это не считая dll-ки). |
|
|
|
|
>в случае с MySQL надо подключать компонент
точно? я потому и написал про ODBC, чтобы было пофигу куда писать, читать и т.п.
впрочем, если сервер не поддерживает хранимые процедуры и маппинг параметров, могут быть особенности. но по идее код один на всех будет, в этом плане несколько типов кэшей дают куда больший оверхэд.
ну да в общем ладно, погляжу на досуге, мне сейчас достаточно подтверждения некой "автономности" перечисленных функций, и скажем так отсутствия сильного "связывания" с остальным кодом, дабы не зря тратить время в этом направлении. ну а коли всё просто и "выделяемо" - будем думать. |
|
|
|
|
|
Там еще проблема, что пока нет механизма переключения типа кэша на лету без перезапуска программы. |
|
|
|
(0004649)
|
|
Garl
|
|
27-12-2011 05:08
|
|
|
может пригодится : http://componentace.com/absolute_database_features.htm |
|
|
|
|
> может пригодится : http://componentace.com/absolute_database_features.htm
Когда его выпустят под GPL будем смотреть. А пока увы. |
|
|
|
(0004652)
|
|
zed
|
|
27-12-2011 09:43
|
|
Может кто подскажет, какой выбрать дефолтный размер страницы (pagesize) для БД? Диапазон возможных значений: 512 байт - 64 Кб. Вот тут расписано про это http://pybsddb.sourceforge.net/ref/am_conf/pagesize.html
Я по-умолчанию поставил 64k, но БД получается слегка пухлой и может быть чуть ли не в 2 раза больше, чем собственно записанные в неё данные.
Приаттачил exe с дефолтным значением 512 байт + утилитку, которая показывает статистику по отдельно-взятой БД. Расшифровка статистики тут: http://pybsddb.sourceforge.net/api_c/db_stat.html (смотреть для Btree).
И к слову, в GoogleMV, которая тоже когда-то юзала беркли, страница была 1024 байт. |
|
|
|
|
>дефолтный размер страницы
Ставь 4k (почти всегда будет оптимально) или 8k (только если есть реально широкие таблицы). Всё что больше - реально имеет смысл только для OLAP. Это относится к "взрослым" БД, у тебя же тут могут быть особенности, но очевидно лишь в плане снижения размера страницы. Я б больше 4k даже не тестил. Впрочем 512 я б тоже не стал, выбери 1k или 2k да и загони туда для теста яндексссатЪ. |
|
|
|
(0004656)
|
|
zed
|
|
27-12-2011 12:16
|
|
>только если есть реально широкие таблицы
Кхм, а тут нету таблиц вообще, тут блобы только. И целиком блобы не влезут в страницу, вплоть до 32k. А если блоб в страницу не влазит, то невлезающая часть пишется в так называемые overflow страницы.
А вот интересная математика: скачал в SAS регион 33*33 тайла (всего 1089), по завершении SAS написал, что загружено 16.1 МБ, эти тайлы легли в БД и заняли там 17.2 МБ (это при pagesize=512) или 18.3 МБ (при pagesize=4k). Эти же тайлы, распакованные в родной формат кэша SAS уже занимают 22,7 МБ (а на диске так вообще 34,0 МБ). Собственно, вообще не понятно почему в распакованном варианте они весят 22 МБ (если это без учёта размера кластера), ну да ладно.
Выходит, что с точки зрения размера БД, оптимальной будет страница в 512 байт, но с точки зрения быстродействия, скорее всего это будет не очень оптимально (число страниц возрастает в разы).
Без профайлера походу не разобраться... |
|
|
|
|
|
Ну то что с точки зрения размера 512 лучше было понятно сразу. А вот что бы понять разницу в скорости нужно писать отдельные тесты |
|
|
|
(0004660)
|
|
Tolik
|
|
27-12-2011 14:50
|
|
О, очень нужная фича!
Что-то я не понял, как его включить.
Поставил Default cache type = BerkeleyDB, перегрузил программу, поелозил по карте - никаких файлов db не увидел. Хотя в zmp CacheType не определён.
Кстати, какой CacheType в zmp соотв. BerkeleyDB? |
|
|
|
|
|
Я кажется уже писал что переключения на новый формат на лету пока нет. Смена типа кэша только после перезапуска программы. |
|
|
|
(0004662)
|
|
Tolik
|
27-12-2011 14:58
(edited on: 27-12-2011 15:04) |
|
Оказывается, CacheType=2 был почему-то указан в maps.ini.
После нажатия кнопки "All by default" в настройках карты эта строка стёрлась, появилась директория cache_db.
Поначалу туда стали писаться png, но после ещё одного рестарта появились наконец-то db!
Хорошо, потестируем :)
Конвертер форматов SAS.Planet -> BerkeleyDB писать будем? Открыл бы хотелку, да это к Планете уже не относится..
P.S. теперь в maps.ini пишется CacheType=6 (это ответ на мой предыдущий вопрос). А нафига он туда вообще пишется?
|
|
|
|
(0004663)
|
|
zed
|
|
27-12-2011 15:10
|
|
>Кстати, какой CacheType в zmp соотв. BerkeleyDB
6
>Конвертер форматов SAS.Planet -> BerkeleyDB писать будем?
Будем, наверное ) |
|
|
|
(0004664)
|
|
Tolik
|
|
27-12-2011 15:15
|
|
Интересно, а CacheType=5 - это что?
Вы уж напишите конвертер, очень просим :)
(сорри за офтопик) |
|
|
|
|
CacheType=5
Это кэш Google Earth |
|
|
|
(0004677)
|
|
Tolik
|
|
28-12-2011 05:16
|
|
Какие существуют утилиты для работы с такими db?
Например, посмотреть содержимое, удалить/добавить тайл в БД и т.п.? |
|
|
|
|
|
Скорее всего утилит нету. Наверное нужно сменить расширение с ".db" на что-то типа ".sas_db" и сделать wcx плагин для Total Commander. |
|
|
|
(0004680)
|
|
zed
|
|
28-12-2011 06:41
|
|
|
А смысл вообще что-то делать вручную внутри БД? |
|
|
|
|
|
Ну это уже другой вопрос. Но ИМХО сменить расширение все-таки стоит. |
|
|
|
(0004682)
|
|
Tolik
|
|
28-12-2011 07:11
|
|
Например, .sdb
Ну взять и закинуть туду тотал коммандером свой старый кэш...
Или удалить какие-то тайлы... |
|
|
|
(0004685)
|
|
zed
|
|
28-12-2011 09:02
|
|
|
Можно и .sdb + нужно сортировку по папкам наверное переделать (вопрос - как) и определиться с дополнительными полями в БД. Сейчас там сохраняется X,Y (key), размер тайла, дата создания тайла ну и собственно, сам тайл. Т.е. вся та же информация, что и в текущем тайловом кэше. Что ещё туда можно/нужно записать? Забить на всякий случай ещё текстовое поле для версии тайла, авось когда и пригодится? |
|
|
|
(0004686)
|
|
Tolik
|
28-12-2011 09:18
(edited on: 28-12-2011 09:19) |
|
> нужно сортировку по папкам наверное переделать
Почему нет Y/1024? Какое макс. кол-во файлов в папке X/1024?
> Забить на всякий случай ещё текстовое поле
не помешает, пожалуй
|
|
|
|
(0004697)
|
|
zed
|
|
28-12-2011 16:55
|
|
В папке X/1024 должно быть не более 1024 папки, в каждой из которых по 16k файлов БД. Если ввести ещё сортировку по Y/1024, то в итоге, в каждой папке у нас будет всего по 16 файлов БД. Можно ввести сортировку не по 1024, а по 256 элементов, тогда в каждой папке будет одинаковое число подпапок/файлов БД (256), но получится избыточное количество папок...
Это если я не ошибаюсь в прикидках. |
|
|
|
(0004698)
|
|
Tolik
|
|
28-12-2011 17:29
|
|
> В папке X/1024 должно быть не более 1024 папки
Не, что-то напутали. Сейчас в папке Х/1024 лежат файлы db.
Например, z20\309\1236.640.db
Поэтому я подумал, что файлов может быть очень много. А сколько именно - не соображу. |
|
|
|
(0004699)
|
|
zed
|
28-12-2011 17:31
(edited on: 28-12-2011 17:35) |
|
В приведенном примере папка X/1024 это папка 309 и да, в ней будет не более 16k файлов БД. А в каждом файле БД лежит 64k тайлов.
|
|
|
|
(0004701)
|
|
zed
|
|
28-12-2011 18:22
|
|
>На зуме 24 2^24 тайлов
Не, по стороне X на определённом зуме 2^(z-1) тайлов, т.е. на 24-м зуме у нас (2^23)*(2^23) |
|
|
|
(0004702)
|
|
Tolik
|
|
28-12-2011 18:44
|
|
Блин, всё сначала.
На 24-м зуме всего (2^23)*(2^23)= 2^46 тайлов (охренеть как много)
В файле db 2^16 тайлов
Всего 2^46 / 2^16 = 2^30 файлов db
Если сделать папку X/1024, в ней будет 2^30 / 2^10 = 2^20 файлов = миллион - это много.
Значит, нужна папка Y/1024, в ней будет 2^10 = 1024 файла БД.
Или опять ошибся? |
|
|
|
(0004703)
|
|
zed
|
28-12-2011 18:59
(edited on: 28-12-2011 19:06) |
|
Похоже на правду.
P.S. А один файл БД весит примерно 1,5 Gb, так что для 24-го зума нам нужно... 1024*1024 Tb :)
|
|
|
|
(0004705)
|
|
Tolik
|
|
28-12-2011 20:57
|
|
Всё-таки, кажется, ошибся.
Если сделать папку X/1024, таких папок будет 2^23 / 1024 = 2^13.
Cледовательно, в каждой папке будет 2^30 / 2^13 = 2^17 файлов = 131072 - это не много.
:-\ |
|
|
|
(0004715)
|
|
Tolik
|
|
29-12-2011 08:40
|
|
|
Кстати, в операцию копирования не забудьте добавить новый формат. |
|
|
|
(0004718)
|
|
zed
|
|
29-12-2011 13:40
|
|
|
Таки папку Y/1024 наверное добавлю на всякий случай. |
|
|
|
(0004722)
|
|
Tolik
|
29-12-2011 15:21
(edited on: 29-12-2011 15:28) |
|
Это мне тоже нравится, т.к. симметрично как-то. Но в папках почти всегда будет ровно 1 файл, максимум 16 (если я опять ничего не напутал).
Может, как-то так?
z<Z>\<X/4096>\<Y/4096>\<X/256>.<Y/256>.sdb
В этом случае уменьшится число папок. Максимум будет 2К папок, в папке макс. 256 файлов - красота :)
|
|
|
|
(0004724)
|
|
Garl
|
|
29-12-2011 16:08
|
|
мужчины, а чем собственно плохо большое количество папок?
всётаки аля классический кэш как то приятней. |
|
|
|
(0004725)
|
|
Tolik
|
|
29-12-2011 16:17
|
|
Ну чем меньше, тем лучше...
Много файлов/директорий - много места тратится напрасно на хранение всего этого, много времени на копирование и т.д. |
|
|
|
(0004727)
|
|
Garl
|
|
29-12-2011 16:25
|
|
|
на спичках (папках) экономить? |
|
|
|
(0004728)
|
|
Tolik
|
|
29-12-2011 16:33
|
|
Ну а почему бы не сэкономить? Ради чего вобще БД? Именно чтобы избавиться от миллионов маленьких файлов.
А какой плюс в привычной структуре? |
|
|
|
|
>много времени на копирование
это пока не надо внутрь файлов при копировании лезть. как только копирование в существующий кэш потребуют слить 2 файлика в один - там ещё бабка надвое сказала что быстрее будет. |
|
|
|
(0004747)
|
|
Fetser
|
|
30-12-2011 15:48
|
|
Попробовал сравнить размеры папок при старом и новом кэш. При увеличении количества тайлов начинает сильно проигрывать вариант с базой данных. См рис. (слева новый формат)
Это неизбежная плата за то что вместо большого количества маленьких файлов один большой? |
|
|
|
(0004748)
|
|
Tolik
|
|
30-12-2011 18:28
|
|
Здесь же выше Zed про это писал:
http://sasgis.org/mantis/view.php?id=124#c4652
Проверьте то же самое на приаттаченной версии SASPlanet.db.512.zip, интересно, что получится.
Также интересно узнать, сколько реально места занимают все эти файлы с учётом кластеров. |
|
|
|
(0004749)
|
|
Fetser
|
|
30-12-2011 19:37
|
|
|
Проделал тоже самое для кластера 512 картинку приложил (512 слева) |
|
|
|
(0004750)
|
|
Tolik
|
|
30-12-2011 20:03
|
|
Можно подробнее?
1. Что слева и что справа на картинках 1 и 2?
2. Что означают цифры: общий размер папки с учётом кластеров (файловой системы) или без?
3. Если с учётом, то какой размер кластера?
4. Как получили разные виды кэша? |
|
|
|
(0004751)
|
|
Fetser
|
|
30-12-2011 20:25
|
|
На всех картинках яндекс карты
На первой картинке справа кэш старый (на диске 127 Мб диск созданный TrueCrypt размер кластера 512)
слева новый кеш в виде базы данных файл SAS.Planet.Nightly.4747 (на диске 240 Мб кластер 4 кБ)
на второй картинке справа новый кэш файл SAS.Planet.Nightly.4747 (на диске 240 Мб кластер 4 кБ)
слева новый кеш файл SASPlanet.db.512 (на диске 140 Мб кластер 4 кБ) |
|
|
|
(0004752)
|
|
zed
|
|
30-12-2011 22:03
|
|
>при старом и новом кэш
Это не _новый_ кэш, а _ещё_один_ кэш и не претендует на кэш по-умолчанию.
>Это неизбежная плата
Ну так а как вы думали, естественно. Ведь в БД помимо самих тайлов нужно ещё и служебную информацию где-то хранить (а вы, кстати, ещё сравните с учётом MFT таблицы - на миллионах тайлов она ведь тоже изрядно тяжёлая).
По поводу pagesize: уже провёл кое-какие тесты и размер в 1k выглядит довольно не плохо, но надо ещё по-плотнее посмотреть. |
|
|
|
(0004754)
|
|
Tolik
|
|
31-12-2011 09:13
|
|
Ну почему же не претендует. Через некоторое время, когда всё будет доделано и хорошо проверено, можно сделать по умолчанию. Потому что миллионы файлов - это очень плохо.
Интересно, какие тесты проведены, какие результаты? Надо ли ещё что-то затестировать? |
|
|
|
|
|
Я может глупость спрошу, но тем не менее, этот формат будет соответствовать формату кэша для RMaps или нет? Если да, может так его и обозвать? |
|
|
|
(0004756)
|
|
zed
|
31-12-2011 13:06
(edited on: 31-12-2011 13:09) |
|
>Интересно, какие тесты проведены, какие результаты?
Результаты будут оглашены и тестовую утилитку тоже выложу, чтоб каждый желающий мог поиграться с параметрами.
>будет соответствовать формату кэша для RMaps или нет
А что у него там за формат? Я как-то и без понятия вообще.
P.S. Что-то этот тикет перерастает в какую-то матроску, может вынести обсуждение на форум?
|
|
|
|
(0004757)
|
|
Tolik
|
|
31-12-2011 14:08
|
|
Если не ошибаюсь, Rmaps - SQLite, т.е. другой формат.
Зачем выносить, пусть обсуждение будет тут, пока не resolved. |
|
|
|
(0004758)
|
|
Fetser
|
31-12-2011 18:01
(edited on: 31-12-2011 18:03) |
|
Когда экспериментировал с файлом SASPlanet.db.512 При ПКМ Операции с выделенной областью постоянно вылетала ошибка, на работоспособность программы это не влияло, но на всякий случай прикладываю elf (кэш каждый раз удалял полностью, то есть это не из за того что существовал кэш созданный другим файлом)
|
|
|
|
(0004759)
|
|
Tolik
|
01-01-2012 15:34
(edited on: 01-01-2012 17:04) |
|
Версия 4758.
1. В меню Параметры карты переключение типа кэша требует перезапуска.
Т.е. в моём случае стоит по умолчанию Беркли, для одной карты (скачанной ранее) ставлю Сас, карта появляется только после перезапуска.
2. При копировании в формат Сас к пути добавляется директория с именем кэша, а при копировании в формат Беркли нет.
3. В целом всё супер. Pagesize 1k.
Размер исходного кэша в формате Сас - 430 MB, с учётом кластеров 490 МБ, 30318 файлов (кластер 4K).
После копирования в Беркли - 458 МБ, с учётом кластеров 458 МБ, 14 файлов.
4. После обратной конверсии (копирования того же кэша из Беркли в Сас) получаем в точности тот же набор файлов (что не может не радовать!)
|
|
|
|
(0004760)
|
|
Fetser
|
|
01-01-2012 20:00
|
|
|
Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту (не дав заполнению полностью нарисоваться)То карта перестаёт подгружаться (в кэш она точно есть) Даже если отключить карту заполнения слоя, то всё равно карта перестаёт появляется на экране. Виден только тот участок что был первоначально, не помогает и смена масштаба. Новый зум не появляется. Спасает только перезагрузка программы. |
|
|
|
(0004761)
|
|
zed
|
|
01-01-2012 20:37
|
|
>Когда экспериментировал с файлом SASPlanet.db.512 При ПКМ Операции с выделенной областью постоянно вылетала ошибка,
Да, было. Уже пофиксили. К кэшу никак не относится
>1. В меню Параметры карты переключение типа кэша требует перезапуска
Да, и не важно какой тип кэша выбран. Т.е. это в отдельную хотелку/баг оформляйте.
>2. При копировании в формат Сас к пути добавляется директория
Исправил
>Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту
Насколько большая разница между текущим зумом и зумом для которого строится карта?
P.S. Завтрашняя сборка не будет понимать сегодняшний кэш, я там ещё одно поле добавил (надеюсь, больше уже добавлять/менять ничего не придётся). |
|
|
|
(0004762)
|
|
Fetser
|
|
02-01-2012 06:15
|
|
>Кэш Беркли 3 Гб. Если включить карту заполнения слоя, потом сдвинуть карту
Насколько большая разница между текущим зумом и зумом для которого строится карта?
Карта была 7 зум, карта заполнения 11 |
|
|
|
(0004763)
|
|
zed
|
|
02-01-2012 07:53
|
|
Прикрепил результаты тестов и утилитку (инструкция в readme).
Что могу сказать: в этом тесте (и на моей системе) операции Read и Exists проходят практически молниеносно при любом значении pagesize и на них как бы можно внимание не заострять. Наиболее длительные операции это Write и Del, и что интересно, при pagesize=1024 оказываются наиболее быстрыми (причём, даже в разы!). Ещё тёмной лошадкой остаётся размер озу-шного кэша БД (cachesize), я его всюду ставил на дефолт (256k), а при увеличении наоборот наблюдаются тормоза. И ещё отрицательный момент большого кэша - при закрытии программе придётся "висеть", пока он не будет сброшен на винт, и соответственно чем больше кэш, тем дольше висим. С другой стороны, при множественных обращениях к одному и тому же тайлу бОльший кэш будет только на пользу. Так что тут ХЗ. |
|
|
|
(0004764)
|
|
T_Im
|
|
02-01-2012 10:38
|
|
|
Может стоит опционально добавить еще один тип кеша - "все в одном файле"? Такой тип кеш более удобен с точки зрения пользователя для обмена и хранения небольших снимков и областей. |
|
|
|
(0004765)
|
|
Fetser
|
02-01-2012 11:29
(edited on: 02-01-2012 11:51) |
|
Версия 4759 Увы баг с нежеланием отображать карту из нового кэш остался, даже нет необходимости включать карту заполнения слоя, достаточно несколько раз поменять масштаб и карта перестаёт перерисовываться. Может это из за того что у меня всего 1 Гб ОЗУ? С удивлением обнаружил что суммарный обьём кеша Беркли меньше сумарного состоящего из тайлов (3134 Мб-Беркли, 3384 Мб-тайловый)и это без учёта размещения на диске. Если с учётом, то выигрыш ещё больше. Если 40 файлов беркли сжать ещё архиватором для переноса (zip)то размер вообще 2933 Мб
|
|
|
|
(0004766)
|
|
zed
|
|
02-01-2012 13:16
|
|
|
Словил похожего глюка: новые тайлы в режиме просмотра перестали загружаться, но при этом закачки по выделению идут без проблем, так же, если выбрать в менюшке "Загрузить тайл в кэш", то он загружается и отображается. А так же, если переключиться на другую карту, то она работает нормально. |
|
|
|
(0004767)
|
|
Tolik
|
02-01-2012 13:21
(edited on: 02-01-2012 13:35) |
|
> новые тайлы в режиме просмотра перестали загружаться
Такое было и раньше, до появления нового кэша.
Уже как минимум месяц замечаю. Надо открыть новый баг.
|
|
|
|
(0004768)
|
|
Fetser
|
|
02-01-2012 13:55
|
|
|
Поочерёдно сравнивал то со старым кешем, то с новым (конечно перезапуская программу) Со старым завесить программу не получается всё работает. А с новым она вешается через несколько минут интенсивного сдвигания карты и смены масштаба. В процессах после того как программа повисла и я ничего более от неё не требую процесс sasplanet грузит процессор на 40% и так продолжается бесконечно долго. ни сменить карту ни загрузить тайл не получается, но само поле легко двигается (определяю по меткам) |
|
|
|
(0004769)
|
|
Tolik
|
02-01-2012 13:56
(edited on: 02-01-2012 14:11) |
|
У меня такого не было ни разу. ОЗУ тоже 1 МБ. Правда, кэш не такой большой.
Пожалуй, стоит тоже открыть отдельный баг репорт.
|
|
SASPlanet.db.512.zip (2,722,536) 27-12-2011 09:43
1.jpg (15,054) 30-12-2011 15:48
SASPlanet.db.512.elf (39,448) 31-12-2011 18:02