100KB sessions will mainly be an issue if you're clustering your sessions, thus forcing network operations and serialization of the session state. This is especially an issue for platforms that use multicast for updates. You didn't specify your app server, but most mainstream implementations transfer the complete session as a single network operation and individually serialize-deserialize each session attribute.
With these assumptions, breaking up the graph will probably increase serialized size a bit. But if the typical request accesses only a portion of the graph, then this approach may be more efficient as you'll pay the full serialization-deserialization cost only for the changed attributes.
I wrote a BEA dev2dev article on clustered session management
a while back that goes into a bit more detail ... it discusses Tangosol Coherence and BEA WebLogic session management, but the concepts are fairly generic.
On most app servers, it's a rule of thumb to try to keep sessions in the ~1KB to ~10KB range. Unless your session access is very read-heavy, going beyond this may mean finding a more efficient approach to session management (either a packaged solution or added development effort).