View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002224 | SAS.Планета | Рефакторинг / Refactoring | public | 24-10-2013 10:50 | 08-01-2014 16:56 |
| Reporter | vdemidov | Assigned To | zed | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 121010 | ||||
| Target Version | 140303 | Fixed in Version | 140303 | ||
| Summary | 0002224: Убрать создание отдельного INotifier для каждого запроса на закачку тайла | ||||
| Description | Сейчас для каждого запроса на закачку тайла создается отдельный нотифаер, а это достаточно дорогой объект с примитивом синхронизации. Вполне реально сделать пул нотифаеров в подсистеме закачки и использовать их по очереди. Возможно два варианта: 1. Как и сейчас считать что если мы подписались на нотифаер запроса на закачку и пришло уведомление, то значит запрос выполнен, не обращая внимамание на сообщение в запросе. Тогда нельзя использовать один нотифаер в нескольких закачках. 2. При получении уведомления от нотифаера проверять наш ли запрос выполился и если не наш, то продолжать ждать следующего. Тогда можно ограничиться даже одним нотифаером. Мне этот вариант нравится больше. | ||||
| Tags | No tags attached. | ||||
| related to | 0002223 | confirmed | Переделать закачку видимой области карты |
|
|
Вариант 3: использовать обычный CallBack. Тем более, что сейчас этот нотифаер так и используется - у него всегда один листнер и он в том же классе, который создаёт нотифаера. Таким образом, передав в конструктор TTileRequestTask наш коллбэк, получим профит в простоте реализации (без пула) и отсутствии оверхэда на примитивах синхронизации. |
|
|
Ещё плюсом будет то, что в коллбэке можно будет передать сразу 2 параметра: ITileRequestTask (Self) и ITileRequestResult из-за чего мы cможем смело прибить метод TTileRequestTask.GetResult и избавиться от ещё одной синхронизации. |
|
|
Может и так. Только нужно внимательно смотреть, за подсчетом ссылок и за временем жизни, а то могут быть очень веселые эффекты. Плюс в качестве CallBack нужно будет объявлять или отдельный интерфейс, или делать простую функцию, а объект передавать через обычный указатель (procedure of object в интерфейсе качалки использовать очень не хочется, что бы не привязываться к делфовским типам) |
|
|
> procedure of object в интерфейсе качалки использовать очень не хочется А интерфейса качалки оно и не коснётся. Качалка вызывает метод ITileRequestTaskInternal.SetFinished(const AResult: ITileRequestResult) |
|
|
Да, пришлось таки коллбэк обернуть в интерфейс. И ещё попутный момент: а почему в этом же TTileRequestTask для отмены операции используется именно INotifierOneOperation, а не обычный INotifierOperation? Там же тоже оверхэд появляется на каждый запрос. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 24-10-2013 10:50 | vdemidov | New Issue | |
| 24-10-2013 10:51 | vdemidov | Status | new => confirmed |
| 24-10-2013 10:51 | vdemidov | Relationship added | parent of 0002223 |
| 04-11-2013 14:22 | vdemidov | Target Version | 41xxxx => 140303 |
| 08-01-2014 04:42 | zed | Note Added: 0013504 | |
| 08-01-2014 05:35 | zed | Note Added: 0013506 | |
| 08-01-2014 07:44 | vdemidov | Note Added: 0013508 | |
| 08-01-2014 10:25 | zed | Note Added: 0013513 | |
| 08-01-2014 16:54 | zed | Note Added: 0013529 | |
| 08-01-2014 16:56 | zed | Relationship replaced | related to 0002223 |
| 08-01-2014 16:56 | zed | Status | confirmed => resolved |
| 08-01-2014 16:56 | zed | Fixed in Version | => 140303 |
| 08-01-2014 16:56 | zed | Resolution | open => fixed |
| 08-01-2014 16:56 | zed | Assigned To | => zed |
| 08-08-2025 13:25 | zed | Category | Рефакторинг => Рефакторинг / Refactoring |