#12010: Document the GEOS IO Classes
-------------------------------+--------------------------------------------
Reporter: James | Owner: jbronn
Status: assigned | Milestone:
Component: GIS | Version: 1.1
Resolution: | Keywords:
Stage: Accepted | Has_patch: 0
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------+--------------------------------------------
Comment (by James):
Thanks for the response. It would be great if hex did as advertised and
simply did this for us vs having to know about and use the capi wrappers.
I have some additional timing info to give since I did a bunch of
profiling on these different approaches of retrieving the hex of the
extended WKP.
So I did some timings on several methods and here were the results:
{{{
getEWKBHEX 0.59
hex 0.23
write_hex 0.22
str 0.01
encode 0.02
}}}
Each timing test profiles the time it takes to run ~10000 calls of each
use case.
'getEWKBHEX' is my optimized code of the original snipet I provided. It
is almost 20% faster then the original snippet, but is much slower then
the other methods which doesn't surprise me since I must use the pack and
unpack methods from python.
'hex' is the current implementation for GEOSGeometry.hex, which doesn't
really do HEXEWKB.
'write_hex' is the capi wrapper call jbronn mentioned. The timing makes
in all my trials it is slightly faster then the hex implementation, which
is odd but probably has to do with data alignments in the native C library
or simply the overhead costs between the two functions to cross the python
to native c boundries.
'str' + 'encode' timings (0.03) is the total time needed to simply encode
the GEOSGeometry.wkp field to hex. This is what was suggested in the
codebase in the comments for speedup. This proves it, as long as hex
should NOT provide HEXEWKB.
In summary, to do as the docs advertise and GEOSGeometry.hex should return
HEXEWKB embedding the CAPI calls as shown by jbronn would not adversely
affect performance. However, if the behavior must stay the same making
the modifications to do a direct encode of the wkp field vs. calling
through the underlying api would provide a large speed increase.
If anyone is interested here is the profiling code I used:
{{{
import time
def timing(f, n, a):
if f.__name__:
print f.__name__,
r = range(n)
t1 = time.clock()
for i in r:
f(*a); f(*a); f(*a); f(*a); f(*a); f(*a); f(*a); f(*a); f(*a);
f(*a)
t2 = time.clock()
print round(t2-t1, 3)
from django.contrib.gis.geos import GEOSGeometry, WKBWriter
if __name__ == '__main__':
wkb_w = WKBWriter()
wkb_w.srid = True
g=GEOSGeometry("POINT(1 2)", srid=4326)
timing(getEWKBHEX, 1000, (g,))
timing(GEOSGeometry.hex.fget, 1000, (g,))
timing(wkb_w.write_hex, 1000, (g,))
timing(str, 1000, (g.wkb,))
timing(str.encode, 1000, (str(g.wkb),'HEX' ))
}}}
--
Ticket URL: <http://code.djangoproject.com/ticket/12010#comment:5>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
