Re: Speeding up loading snapshots
Karl Wettin <[email protected]>
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <[email protected]> |
On Jan 25, 2011, at 2:57 AM, Justin T. Sampson wrote: > >> On Mon, Jan 24, 2011 at 4:13 PM, Karl Wettin <[email protected]> wrote: >> I'm sort of tired of having to wait for my 5GB application to start up. >> >> To me the bottleneck seems to be that only one thread can be used to load a snapshot. >> > That's true if the CPU overhead of deserialization is greater than the disk overhead of reading the snapshot file. If reading a snapshot is I/O-bound then multithreading wouldn't help much. Have you done any profiling to determine how much time is spent in I/O vs. CPU? I'm pretty sure that other people have found the CPU to be significant, so you're probably on the right track anyway. It sure is CPU bound. Java take relative much time to instantiate objects, which is what java.io.Serializable does and what I think VM dependent heap dumps wouldn't have to do. > Another thing that can simplify serialization is to force your data model into a tree structure so that cross-references aren't needed during serialization and deserialization. That won't save anything using Java serialization, but some other serializers (such as XStream) have optimized modes that can take advantage of that property. Aha, I'll check it out. I'm however a bit stuck with java.io.Externalizable and Serializable for now though. karl ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org