Just to be short, I would like to give You few (mostly general) tips on making using LLBL with serialization faster.
Problem:
If you use LLBL in ASP.NET you may need to store some whole entity (even collection) in session state. If you make CPU/memory analysis, serialization of this data is probably very significant in Your project (of course if you need to use SessionState or SqlState server).
Solution 1:
Do not store whole entity in session. Persist entity into database and store only ID to this entity.
- this solution has obvious problems with dealing with temporary rows in database (deleting old records, database size, fragmentation, ...)
Avoiding solution 1:
- when you first created your LLBL project, you probably enabled all entities, all relations (just to be sure to find them if you need them). Always try to keep your LLBL project as thin as possible. Hiding m:n relations (relations like SexCollectionViaUser) which are probably not used anyway alone could save you up to 30% of the serialized entity size.
- hide not used fields. You could use some custom binary fields i.e. for data replication etc. Hide them if you don't need them in your code. LLBL always fetch whole data row.
PS: I hope LLBL 2.1 new Fast Serialization will speed up session state serialization even more. It is very easy to make own session state engine, which serialize data with custom serializer. Serializing with binary serializer to plain files is indeed faster then using asp.net session state server (though I need to check scalability). Custom session state has another advantage. You do not have to deserialize whole session state for one entity (as native asp session state server does). If I have 10 big entities in session, I choose only one I need in this postback.
Even if you do not need to serialize LLBL entities, keeping llbl project as small as possible will also lower memory consumption.
