Le dimanche 31 août 2014 22:44:00, Robert Coup a écrit : > Excellent :) > > There's obviously no nice run-time solution using the C++ API,
Yes, that could be possible if the C++ public API had redirection to driver implementation methods. In GDAL, we have that with some methods like RasterIO() vs IRasterIO(). In OGR, that only exists now with CreateLayer() / ICreateLayer() (change done during RFC46) > though I > guess callgrind/linux-perf can do it - do you have any experience worth > sharing there? Hum, my OGR API Spy hasn't been design to do performance profiling. That would require a pre- and post- calls. Long time ago, I had use callgrind, but not with GDAL. Works, slowly, and AFAIR can only measure CPU time, whereas GDAL does typically lots of I/O, so CPU time isn't always very significant. A more lightweight and faster solution that I've sometimes used is sysprof (not sure this is really maintained). Only sees CPU activity too. > > Rob. > > > On Mon, Sep 1, 2014 at 7:14 AM, Even Rouault <[email protected]> > > wrote: > > Le dimanche 31 août 2014 20:50:41, Robert Coup a écrit : > > > That's cool :) Is there any particular performance penalty to compiling > > > *with* OGRAPISPY_ENABLED and then running *without* > > > OGR_API_SPY_FILE/OGR_API_SPY_SNAPSHOT_PATH > > > set? > > > > Hi Robert, > > > > Hopefully no, see for example : > > > > OGRFeatureH OGR_L_GetNextFeature( OGRLayerH hLayer ) > > > > { > > > > VALIDATE_POINTER1( hLayer, "OGR_L_GetNextFeature", NULL ); > > > > #ifdef OGRAPISPY_ENABLED > > > > if( bOGRAPISpyEnabled ) > > > > OGRAPISpy_L_GetNextFeature(hLayer); > > > > #endif > > > > return (OGRFeatureH) ((OGRLayer *)hLayer)->GetNextFeature(); > > > > } > > > > I cannot imagine something with less overhead. (if you exclude dynamic > > binary > > patching techniques ;-) ) > > > > OGROpen() and OGR_Dr_CreateDataSource() call a tracing function that > > tests if > > the env. variable is set, and if so set the boolean bOGRAPISpyEnabled. > > > > Even > > > > > Rob :) > > > > > > > > > On Sun, Aug 31, 2014 at 11:34 PM, Even Rouault < > > > > [email protected]> > > > > > wrote: > > > > Hi, > > > > > > > > This will not be of interest for the crowds, but mainly for OGR > > > > driver developers (and potentially also to get precise bug reports > > > > from > > > > users). > > > > > > I'm > > > > currently adding update capabilities to the MITAB driver, and while > > > > playing with QGIS, there are sometimes sequences of OGR calls that > > > > trigger bugs, but > > > > that I had issues to replicate afterwards. This spy mechanism enables > > > > to > > > > > > have > > > > recording of all relevant calls to be able to replicate them exactly > > > > afterwards. > > > > > > > > Doc to use it : http://www.gdal.org/ograpispy_8h.html > > > > > > > > Related autotest script : > > > > http://svn.osgeo.org/gdal/trunk/autotest/ogr/ograpispy.py > > > > > > > > Even > > > > > > > > -- > > > > Spatialys - Geospatial professional services > > > > http://www.spatialys.com > > > > _______________________________________________ > > > > gdal-dev mailing list > > > > [email protected] > > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
