Bloated object size in CSLA 3.8.

Bloated object size in CSLA 3.8.

Old forum URL: forums.lhotka.net/forums/t/7610.aspx


Eric_a posted on Friday, September 11, 2009

My company just upgraded from CSLA 3.05 to CSLA 3.8. We use CSLA in a 3 tier configuration the vast majority of the time. I decided to do an object size comparison of the old way of passing data as raw primitive types and compare the object size using the new PropertyInfos. I discovered on a 5 property editable collection with 61 rows. The old way of using primitive types came across the wire as 12979 bytes while the new PropertyInfos came across as 44980 bytes. Does anyone know anything about this? Is there any way around it? Where I work we cannot afford that additional overhead. Thanks in advance for any advise.

RockfordLhotka replied on Friday, September 11, 2009

This is a side-effect of the field manager implementation and the way generic types are serialized into XML by .NET. If you actually look at the byte stream you'll see that the vast majority of the bloat consists of redundant xmlns and assembly/type strings.

There's little to be done about that directly - this is how .NET serializes the data.

However, compression is exceedingly effective on this data - partly because XML is just verbose text to start with, and partly because the extra data is the same strings repeated many times.

There are compressed WCF bindings available that generally address this issue in an effective manner.

rfcdejong replied on Saturday, September 12, 2009

There are some topics about this, for example:
http://forums.lhotka.net/forums/thread/26738.aspx

Copyright (c) Marimer LLC