- 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
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Another Struggle with Guids
I don't know what it is with me and Guids. I actually like Guids and their characteristics a lot, but they surprise me every now and then. One big surprise was what I wrote about in a previous article for InformIT: I found a huge slowdown when inserting rows to large tables with Guids (or rather UNIQUEIDENTIFIERs) for primary keys.
I found that when having a Guid field in an instance, that Guid field added 107 bytes to the serialization size!!! When I added one more to the same instance, the second one took 40 bytes. When I changed the code and stored the Guid as a bytearray instead, each Guid took 35 bytes in serialization size (still a lot, but less than the ordinary Guid type).
My new architecture currently assumes a Guid as primary key for each table, but that isn't the case with the tables used for the tests here. Therefore, I used <NonSerialized()> for the Guid variable in order not to make the tests unfair.