[mapguide-internals] Re: RFC110 Profiling API enhancement

[Arthur Liu]

Hi Jackie,

Thanks for your suggestion.

 I think the decorator pattern could help if end users just need some simple profile information. But if it comes to some detailed information like measuring the time for performing a feature class join or getting a spatial context, decorator pattern is not flexible enough. In that situation, we have to apply decorator to these detailed operations, but the high level operation like RenderMap which depends on these detailed operations still need to be updated or copied, right?

Regards,
Arthur

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Jackie Ng
Sent: Thursday, April 28, 2011 9:39 AM
To: mapguide-internals at lists.osgeo.org
Subject: [mapguide-internals] Re: RFC110 Profiling API enhancement

What about using the decorator pattern to create set of instrumented service classes that wraps the respective service class to be profiled and provides the same interface as the class being wrapped.

So something like:

class MgProfiledRenderingService : public MgRenderingService {
private:
    MgRenderService* m_innerService; //The actual object to be profiled
    //Other internal state specific to profiling
    ...

public:
    MgByteReader* RenderMap(...);
    //Other MgRenderingService APIs
    ...

    //The actual profiling APIs
    MgProfileResult* ProfileRenderMap(...);
    ...
};

MgByteReader* MgProfiledRenderingService::RenderMap(...)
{
    Ptr<MgByteReader> result;
    //Start performance measuring here
    result = m_innerService->RenderMap(...);
    //End performance measuring here, and update internal profiling state
    return result.Detach();
}

MgProfileResult* MgProfiledRenderingService::ProfileRenderMap(...)
{
    Ptr<MgProfileResult> result;
    //Call the instrumented API(s)
    //collect the profiled result information and return it
    return result.Detach();
}

This way, the original code does not require any changes at all. Barring any inheritance constraints, most (if not all) MapGuide classes could be profiled in this fashion. These profiled classes need not be made public, and could be just internal to this MgProfilingService.

- Jackie

--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/RFC110-Profiling-API-enhancement-tp6296419p6311760.html
Sent from the MapGuide Internals mailing list archive at Nabble.com.
_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals