[mapguide-internals] RFC60 finalization ... Stylizing

Fri Oct 30 15:31:29 EDT 2009

Go for it.

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: Friday, October 30, 2009 3:29 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] RFC60 finalization ... Stylizing

Thanks that will be helpful to assess the overhead later....

I consider now moving the color parsing into the stylizer....
That looks like the best place as the same data structures are used here.
As the stylizer is pluggable this seems perfect to do comparitive analysis.

Walt, any comments?

Traian Stanev wrote:
> I use the profiler that comes with the Visual Studio Performance Tools. It works well for profiling the MapGuide server and is straightforward to use in sampling mode (which is better than instrumented mode anyway). Given this, it should not take more than 5 minutes to measure the overhead of style parsing if you already have a problematic map: you attach the profiler to the server process, do some map requests that use styles, then detach the profiler and look at the table of sorted function calls it shows as a result.
>
>
> Traian
>
>
>   
>> -----Original Message-----
>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-
>> bounces at lists.osgeo.org] On Behalf Of UV
>> Sent: Friday, October 30, 2009 2:17 PM
>> To: MapGuide Internals Mail List
>> Subject: Re: [mapguide-internals] RFC60 finalization
>>
>> frequently executed code has to be optimal.... I think we can all easily
>> agree that this is straightforward...
>> Any additional symbol lookup which cannot be served straight from the
>> cache is prohibitive.
>>
>> But anyway you mentioned profilers?
>> Its good that they exist. but we have to be able to use them!
>>
>> Some more details maybe?
>>
>> Currently I am tempted to think that improving the symbol cache is
>> easier than doing any measuring.....
>>
>> Traian Stanev wrote:
>>     
>>> I agree. "Could be", "a lot" and "significantly" mean nothing. If you said
>>>       
>> something like "25% of request time for my map is spent parsing symbol
>> definitions", then we can talk about fixing it. Profilers do exist.
>>     
>>> Traian
>>>
>>> ________________________________________
>>> From: mapguide-internals-bounces at lists.osgeo.org [mapguide-internals-
>>>       
>> bounces at lists.osgeo.org] On Behalf Of Walt Welton-Lair [walt.welton-
>> lair at autodesk.com]
>>     
>>> Sent: Monday, October 26, 2009 7:09 PM
>>> To: MapGuide Internals Mail List
>>> Subject: RE: [mapguide-internals] RFC60 finalization
>>>
>>>
>>>       
>>>> Empirically we only know so far that 4 times a small tile takes A LOT
>>>> longer than a tile 4 times bigger .....
>>>>
>>>>         
>>> And that has nothing to do with having one instance of SEMgSymbolManager
>>>       
>> per thread, which was your original concern.
>>     
>>> -----Original Message-----
>>> From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-
>>>       
>> internals-bounces at lists.osgeo.org] On Behalf Of UV
>>     
>>> Sent: Monday, October 26, 2009 6:27 PM
>>> To: MapGuide Internals Mail List
>>> Subject: Re: [mapguide-internals] RFC60 finalization
>>>
>>> inline...
>>> Traian Stanev wrote:
>>>
>>>       
>>>> It's implementing the simplest effective way of caching -- generally you
>>>>         
>> have lots of features sharing the same style within a request and it will
>> only parse the style once for those features. Having a global cache is more
>> complicated because it also has to monitor changes to symbol resources --
>> and it would have been even more annoying to implement back when we
>> theoretically allowed for the resource service to run on a separate machine
>> than the mapping service.
>>     
>>>>         
>>> ... has the plan to move the resource service to another node been
>>> abandonded?
>>> If so this opens the route to more efficient use of the internal map
>>> structures ....
>>>
>>> How big is the share of TileRequests in the general picture?
>>> Maybe this is a good time to ask people for their usage patterns to
>>> collect some statistical usage data....
>>>
>>> However, parallel tile requests to the same scalerange of the same map
>>> seem like a very popular use case ...
>>> ... and they are all sharing identical featuretypestyle data
>>> thus I see a lot of potential to streamline the map cache structures by
>>> tying it more closely to the map data.
>>>
>>> In the context of RFC60 the reuse of the symbolcache for the colorsearch
>>> requires some code changes due to the current scoping of the symbolcache.
>>> A singleton based shared mapobject providing cache structures tied to
>>> the maps lifecycle could be a much more performant approach here.
>>> Sharing mapdata across http requests this way could significantly
>>> improve server performance.
>>>
>>> Any thoughts??
>>>
>>>       
>>>> Do you have any empirical results of a real world map showing that the
>>>>         
>> current implementation results in a high relative overhead of symbol parsing
>> compared to, say, FDO requests, or PNG saving or the symbol stylization
>> itself?
>>     
>>> Empirically we only know so far that 4 times a small tile takes A LOT
>>> longer than a tile 4 times bigger .....
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>> _______________________________________________
>>> mapguide-internals mailing list
>>> mapguide-internals at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>>
>>>
>>>       
>> _______________________________________________
>> mapguide-internals mailing list
>> mapguide-internals at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>>     
> _______________________________________________
> mapguide-internals mailing list
> mapguide-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapguide-internals
>
>   

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals