- A Step Toward Realism
- Overview
- New Architecture Code Examples
- The Usual Type of Client-Side Code
- A Couple of Tweaks that Help Performance
- Collapsed Objects
- Statuses in One Single Byte
- Object Vector
- NonSerialized()
- Using "Dumb" Collections
- Another Struggle with Guids
- Oops, Maintainability Must Be Lost!
- And a Few Tweaks Not Applied Yet
- A New Test Application
- Results of the Throughput Tests
- Conclusion
Collapsed Objects
The objects can be in one of two states: collapsed or expanded. When an object is collapsed, it typically has only a few properties and is read-only. When an object is expanded, it typically has many properties, is writable, and remembers the values found in the database at the time of instantiation. By using collapsed when appropriate, you reduce serialization size but also memory footprint. The typical situation for collapsed is when you want to fill lists, but you should also use it when it works in other situations. Because collapsed works for the tests today, I think it's fair to use it here. To fulfill the tests, I need only to fetch data, not prepare for updates. Therefore, I need only one set of values for each object, and collapsed is ideal.