API read/write perf is poor for Artworks

[markfinger]

Read timing

person 422 records: 0.912145853043 seconds
artwork 983 records: 48.3299021721 seconds

The results are paginated, so there's no extra overhead from json handling a massive payload. Given the extra pages for the artwork records, there may be a negligible overhead associated with the network requests.

Write perf seems to be about the same as reads.

[jmurty]

@markfinger @cogat the poor performance for Artworks, or any work in collections, is caused by the new EDTF field which uses naive and slow parsing of text values when reading EDTF date values back from the DB into model instances.

Fixing this will require either rethinking and updating the EDTFField implementation in python-edtf or removing the field from API results (with defer on the queryset) which would only solve the problem for API operations.

See ixc/python-edtf/issues/14

[jmurty]

As noted in ixc/python-edtf/issues/14 it can take a quarter-second or longer to load each non-empty EDTF date field from the DB into a model instance, whether or not that field is subsequently referred to. This explains why it is slow not just to list items, but even to delete a set of populated model instances with Artwork.objects.all().delete()

[jmurty]

This should be substantially resolved by changes for ixc/python-edtf#11

[jmurty]

This should be resolved enough for now by changes upstream in ixc/python-edtf#11 etc