View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001725 | SAS.Планета | Баг / Bug | public | 05-12-2012 15:51 | 05-12-2012 20:15 |
| Reporter | vasketsov | Assigned To | vasketsov | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | Vista | OS Version | Ultimate |
| Product Version | 121010 | ||||
| Target Version | 131111 | Fixed in Version | 131111 | ||
| Summary | 0001725: При проверке наличия тайла перед закачкой он читается полностью | ||||
| Description | Внури procedure TThreadDownloadTiles.Execute; в строке VTileInfo := FMapType.TileStorage.GetTileInfo( последний параметр равен gtimWithData. Это приводит к тому, что тайл читается полностью. Тогда как требуется только определить его наличие, признак TNE, дату и размер. Необходимо заменить gtimWithData на gtimAsIs. Для любых типов кэша. | ||||
| Tags | No tags attached. | ||||
|
|
Для одной и той же субд для одной и той же прокэшированной области скорость её прохода в режиме "не хочу качать закаченное" отличается примерно в 10 раз )) На ФС не тестил, думаю что отличие будет не меньше, так как атрибуты файла читаются из каталога куда быстрее, чем он даже открывается. Хотя возможны варианты, связанные с фрагментацией папок и т.п. |
|
|
Среди всех 4 поддерживаемых типов хранилищ (GE/GC, файловый, беркли и СУБД) для всех кроме беркли должно наступить резкое улучшение ввиду уменьшения паразитного IO. Для беркли имеется if AMode = gtimWithoutData then begin поэтому ничего не изменится. Но так как по идее признак ненужности загрузки всего тайла целиком для режима отличного от gtimWithData возможно надо переносить чуть выше к FHelper.LoadTile - после исправления в качалке назначим ответственным автора. |
|
|
А вообще забавно, живём так уже 3 месяца с ревизии 6309 - и всем пофигу )) |
|
|
Да там столько тормозов по программе раскидано, что одним больше, одним меньше, на глаз не всегда заметно. :) К тому же это ведь в закачке? А там основные тормоза из-за инета, а не из-за дисковых операций, потому никто и не обратил внимания. |
|
|
>основные тормоза из-за инета, а не из-за дисковых операций Выкачай область, и запусти по ней скачку снова. Разница видна невооружённым взглядом. Примерно на порядок быстрее скачанное пролетает. |
|
|
>А вообще забавно, живём так уже 3 месяца с ревизии 6309 - и всем пофигу )) Ну вот исправил и молодец. А Product Version нужно ставить по возможности ту, где впервые начало наблюдаться. То есть в нашем случае 121010 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 05-12-2012 15:51 | vasketsov | New Issue | |
| 05-12-2012 15:51 | vasketsov | Assigned To | => vasketsov |
| 05-12-2012 15:51 | vasketsov | Status | new => assigned |
| 05-12-2012 15:57 | vasketsov | Note Added: 0010133 | |
| 05-12-2012 16:22 | vasketsov | Note Added: 0010134 | |
| 05-12-2012 16:32 | vasketsov | Note Edited: 0010134 | |
| 05-12-2012 16:32 | vasketsov | Assigned To | vasketsov => zed |
| 05-12-2012 16:34 | vasketsov | Note Added: 0010135 | |
| 05-12-2012 17:07 | Dima2000 | Note Added: 0010137 | |
| 05-12-2012 17:08 | Dima2000 | Note Edited: 0010137 | |
| 05-12-2012 17:26 | vasketsov | Note Added: 0010138 | |
| 05-12-2012 18:15 | vdemidov | Note Added: 0010142 | |
| 05-12-2012 20:15 | vdemidov | Product Version | .Nightly => 121010 |
| 05-12-2012 20:15 | vdemidov | Target Version | => 131111 |
| 05-12-2012 20:15 | vdemidov | Status | assigned => resolved |
| 05-12-2012 20:15 | vdemidov | Fixed in Version | => 131111 |
| 05-12-2012 20:15 | vdemidov | Resolution | open => fixed |
| 05-12-2012 20:15 | vdemidov | Assigned To | zed => vasketsov |
| 08-08-2025 13:22 | zed | Category | Баг => Баг / Bug |