Fix redundant save on every Entity.load() — eliminates unnecessary json.dumps + storage write

[deucalioncodes]

Problem

Every Entity.load() call triggers a full re-serialization and write-back of the entity to storage, even though nothing has changed.

Current load path

storage.get → json.loads → Entity.__init__(**data, _loaded=True) → _save() → serialize() → json.dumps → storage.insert

In __init__, after setting all attributes with _do_not_save=True, the flag is reset and _save() is called unconditionally:

self._do_not_save = True
for k, v in kwargs.items():
    if not k.startswith("_"):
        setattr(self, k, v)
self._do_not_save = False

self._save()  # always runs, even when _loaded=True

_save() then unconditionally serializes and writes back:

data = self.serialize()

if not self._do_not_save:
    db.save(self._type, self._id, persisted_data)  # json.dumps + storage.insert

Impact per load

• 1x json.loads (read from storage)
• 1x serialize() (Python dict construction, MRO walk)
• 1x json.dumps (redundant write-back)
• 1x storage.insert (redundant StableBTreeMap write on canister)
• 1x audit json.dumps (if audit enabled)

That is 3 JSON round-trips + 1 storage write for a read-only operation.

Fix

In __init__, skip _save() when loading an existing entity:

if not self._loaded:
    self._save()

This eliminates the redundant serialize + write on every load, cutting JSON overhead roughly in half for read-heavy workloads.

Notes

• The entity registry and context tracking still happen — only the redundant DB write is skipped.
• When _loaded=True, the data in storage is already up-to-date (we just read it), so writing it back is a no-op with wasted cycles.
• On IC canisters, each storage.insert hits a StableBTreeMap, so the cost is non-trivial.
• Benchmark tests exist in tests/src/tests/test_benchmark.py to measure before/after impact.

[deucalioncodes]

Benchmark Results: Before vs After Fix (PR #3)

CI benchmark runs compared: main baseline (run 23120311532) vs PR #3 (run 23232510674)

load_level1 — primary target of this fix

DB Size	Before (main)	After (PR #3)	Saved	Improvement
0	47,347	46,742	605	~1%
10	5,546,737	3,665,214	1,881,523	34%
50	5,489,643	3,607,697	1,881,946	34%
100	5,495,150	3,597,174	1,897,976	35%
200	5,530,258	3,612,366	1,917,892	35%
500	5,513,712	3,603,725	1,909,987	35%

load_level3

DB Size	Before (main)	After (PR #3)	Saved	Improvement
10	5,505,105	3,617,140	1,887,965	34%
50	5,480,212	3,593,858	1,886,354	34%
100	5,510,470	3,600,034	1,910,436	35%
200	5,537,447	3,616,949	1,920,498	35%
500	5,515,196	3,613,373	1,901,823	34%

deserialize_existing_level1 (upsert path — loads then saves)

DB Size	Before (main)	After (PR #3)	Saved	Improvement
10	7,493,372	5,621,906	1,871,466	25%
50	7,475,635	5,576,374	1,899,261	25%
100	7,516,880	5,608,598	1,908,282	25%
200	7,535,903	5,630,846	1,905,057	25%
500	7,531,294	5,614,321	1,916,973	25%

deserialize_existing_level3

DB Size	Before (main)	After (PR #3)	Saved	Improvement
10	7,465,252	5,586,723	1,878,529	25%
50	7,453,056	5,569,088	1,883,968	25%
100	7,509,970	5,625,759	1,884,211	25%
200	7,529,126	5,613,907	1,915,219	25%
500	7,532,899	5,640,095	1,892,804	25%

Unchanged operations (expected — no load path involved)

Operation	DB Size	Before	After	Δ
create_entity	100	2,549,616	2,539,696	~0%
serialize	100	287,835	287,940	~0%
deserialize_new_level1	100	2,379,362	2,385,122	~0%

Summary

• Entity.load(): ~1.9M instructions saved per call = 34–35% faster
• deserialize_existing: ~1.9M instructions saved = 25% faster
• create_entity, serialize, deserialize_new: unchanged (correct)
• The ~1.9M instruction saving is consistent across all DB sizes and represents the eliminated serialize() + json.dumps() + storage.insert() + audit overhead.