Consider using computed properties instead of lazy properties
hassila opened this issue · comments
The current implementation of lazy properties will significantly increase the memory space required for a given object, as one copy will reside in the buffer backing store and another will at a minimum have a pointer for complex objects or the same size for scalars.
It would probably be interesting to evaluate using computed properties instead that directly returns the data from the backing store (as it should be properly aligned by virtue of the alignment/padding of flat buffers in general, as long as the start of the buffer is aligned appropriately).
It would probably make most sense to do this for simple types like scalars, strings, structs etc, while retaining lazy properties for the more complex ones (embedded tables, arrays) that might be accessed repeatedly.
The rationale would be that the allowance for essentially zero-copy operation without the additional per-instance property storage would give both smaller footprint, which both is good in terms of resource consumption, but may also give possibly better runtime performance due to lower CPU cache utilization (should measure both using larger working sets of objects...).
I just manually switched to computed getters in bench.swift and got slower performance
Lazy run
=================================
4077 ms encode
353 ms decode
4883 ms use
593 ms dealloc
5829 ms decode+use+dealloc
=================================
Total counter is 8644311667000000
Encoded size is 315 bytes, should be 344 if not using unique strings
=================================
Where before I had
Lazy run
=================================
4034 ms encode
541 ms decode
3737 ms use
9 ms dealloc
4287 ms decode+use+dealloc
=================================
Total counter is 8644311667000000
Encoded size is 315 bytes, should be 344 if not using unique strings
=================================
Only decode becomes faster, where use and deal become worst.
Hm I will try again with converting only scalar properties to computed, as we discussed it before.
The mixed approach seems to be not really significant:
Lazy run
=================================
4032 ms encode
514 ms decode
3651 ms use
8 ms dealloc
4173 ms decode+use+dealloc
=================================
Total counter is 8644311667000000
Encoded size is 315 bytes, should be 344 if not using unique strings
=================================
makes only sense if user can replace scalar values and encode again. Which than should be really fast. #17