Conversation
|
I removed the custom class and replaced it with two one line static methods for comparing two dictionaries, which the serializer now uses to maintain partial serializations. Claude's "optimization" basically just replaced the I changed I ran the 300 item test with the following results: So either my code is a legit improvement or I have a faster computer. |
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Instead of two passes (Python dict-building + json.dumps), serialize_json now uses a SpiffEncoder that lets the C-level JSON encoder handle plain data traversal natively, only calling back to Python for registered types. Periodic serialization test (300 items, 180 serializations): | Metric | Before | After | Improvement | |--------------------------------|----------|---------|---------------| | Total time | 162.5s | 45.0s | 3.6x faster | | Total serialization | 160.7s | 43.3s | 3.7x faster | | Avg per serialization | 0.893s | 0.241s | 3.7x faster | | Final checkpoint (308 tasks) | 2.07s | 0.56s | 3.7x faster | Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
refactor serialize_json to use custom JSONEncoder for ~3.7x speedup
This adds a "copy-on-write" strategy that seems to improve performance and reduce the size data during serialization. This was done with claude doing most of the work and recommendations, and me just vetting code and asking questions, and keeping a very tight reign on changes - so that we are making as minimal a change to existing code as possible.
I am not expecting you to merge this, so much as have a hard look at it so we can talk about it tomorrow post scrum.
We still hit recursion limit on 1000 loops, so that particular problem isn't addressed yet.
Performance Tests Prior to Changes:
Performance Tests after Changes: