Well as I said in my email, I have no hard numbers. But complaints about the in-memory size of the SessionFactory have been around forever.

That said, I do eye up suspiciously stuff like the pre-building of SQL statements, Loader instances, etc that occurs within the persister. One option is to build this stuff on first access/use, which I think helps. The cost of reloading versus rebuilding here depends greatly on the SQL being generated which in turn depends greatly on the complexity of the entity.

The other use case I think of is the QueryPlanCache and our very narrow internal caching implementation there. In fact this is the one that really got me thinking it would be best to store in a "real" cache to leverage the caches overflow, eviction, etc capabilities. In fact here, in our internal structure, we actually hard code an eviction policy (yes we allow configuring the parameters of that policy, but the policy itself it hard-coded). If a lookup fails then we simply rebuild it, as you mention. So nothing really changes there. Except the flexibility to more easily (in theory) apply other policies.