[mapserver-dev] symbol lazy-loading

Pavel Iacovlev iacovlev.pavel at gmail.com
Sat Nov 21 11:03:50 EST 2009


In my case I have a lot of symbols that are never used on render
request because of 2 reasons:
1) There are a lot of layers(~20) and they need to be delivered in
real time (so no tile cache or 1 wms request per layer) thats why all
layers are rendered at server side as 1 image. Thats why I can't use
multiple symbolsets.
2) An example of one of this layers is Fire hydrants, based on
attributes I have 12 different types of them (12 images)

I fully understand that my case is not common. Are there are ways to
solve this problem not sacrificing a lot of performance like opening a
lot images and font files on every request ? I think it's a nice
example of what benefits we can is some cases from lazy-loading.

On Sat, Nov 21, 2009 at 3:55 PM, thomas bonfort
<thomas.bonfort at gmail.com> wrote:
> Pavel,
>
> On Wed, Nov 18, 2009 at 13:24, Pavel Iacovlev <iacovlev.pavel at gmail.com>
> wrote:
>>
>> Good day all,
>>
>> As I understood on render request mapserver loads all symbols into
>> memory thats is fine if you have under 64 symbols (default limit).
>
>  recent versions of mapserver aren't limited to 64 symbols anymore.
>
>> I
>> have a topographical map to render that maybe will have around 200+
>> symbols and like 5-10 will be used per request. Maybe implementing
>> lazy-loading (only then needed) for symbols will improve the
>> performance ? and remove the cap at all.
>
> lazy loading of symbols would definitely make sense for image symbols,
> although only for people with a single symbolset for multiple instances, as
> otherwise the case is rarer to have defined  a symbol but never use it.
>
> the other symbol types wouldn't see much benefit from lazy loading imho, as
> this is only a parser operation that has to be done anyways.
>
>>
>> Another question is if I have
>> 100 image symbols all 100 images are loaded into memory on render
>> request ?
>
> yes, all the image files are loaded.
>
> regards,
>
> thomas
>
>



-- 
http://iap.md, The future is open


More information about the mapserver-dev mailing list