On 07 Sep 2013, at 02:03, Peter Aronson <pbaron...@att.net> wrote: > Ah, I see. Yeah, that would be trickier. You could save off the geometry > blob and the GEOSPreparedGeometry object in a structure passed in to > sqlite3_create_function and accessed via sqlite3_user_data and memcmp each > geometry blob with the previous one to see if you need to regenerate the > prepared geometry, but then you'd have to clean it up yourself somehow > afterwards, and the cost of alloc, memcpy calls and memcmp calls would have > to be cheaper than generating the prepared geometry.
That's definitely an option; I'm already using sqlite3_user_data to store a bunch of function pointers that abstract the differences between geopackage, spatialite3 and spatialite4. It's all still pretty crude, but it's starting to get where I want it to be. Adding a fixed size LRU geometry cache to this seems like the way forward, which is essentially what spatialite has done as well. Fixed size LRU avoids the need to have cleanup routines. I would expect the memcmp to not be slower than creating the prepared geometry. Creating that object requires two converting from blob to GEOSGeometry to GEOSPreparedGeometry. I have a hard time imagining that this would be faster than one or two memcmps. Anyway, I'll experiment with this approach and profile it to see if it's worth it. Thanks for the ideas and advice. Pepijn _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
