[mapguide-internals] RE: RFC110 Profiling API enhancement

[Traian Stanev]

Hi Arthur,

Who would be the target user of such an API? It seems to me it would be a MapGuide core developer interested in optimizing MapGuide performance. In such case, what would the API provide above and beyond the Visual Studio built-in sampling profiler?

Wouldn't the time spent in injecting all those checkpoints in the code (which might themselves add a further performance overhead) be better spent optimizing the actual code using existing profiling tools, like the built-in Visual Studio profiler or VTune.

Having spent a lot of time optimizing MapGuide rendering, I find that the above-mentioned tools do an excellent job already.

Traian


-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Arthur Liu
Sent: Friday, April 22, 2011 2:37 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] RFC110 Profiling API enhancement

Hi all,

There's an RFC110(http://trac.osgeo.org/mapguide/wiki/MapGuideRfc110)  about providing some profiling APIs to help identify MapGuide performance bottlenecks.

Before making this RFC be reviewed formally, I would like to know you experts' ideas about following questions:


1.      Which of the following implementation is better?

a.      Solution 1:

Copy the implementation of profiling related APIs to MgServerProfilingService and add profiling code into the copied version.

For example, to profile the map rendering process, we need to copy the implementation of RenderMap in MgServerRenderingService(and all other MG server APIs being invoked in RenderMap) to MgServerProfilingService. The advantage and disadvantage of this implementation is obvious: less influence on the original implementation but heavy maintenance to do in the future.



b.      Solution 2:

Inject the profiling code into the original functions being profiled directly, which means MgServerServices should be extended to accept a ProfileResult and the implementation of some APIs will updated to support profiling.

For example, to support profiling RenderMap, all the MgServerServices in the RenderMap workflow will be affected - MgServerRenderingService, MgServerResourceService, MgServerFeatureService, MgServerDescribeSchema, MgServerSelectFeatures, etc.  Some new internal interface like Get/SetProfileResult should be added to these MgServerServices.


For both solutions, how many code should be copied or updated will be decided by how detailed the information would be gathered.



2.      Is it a good idea that we take the advantage of MdfModel and MdfParser to store the ProfileResult object model and do the serialization?


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