Re: Speeding up loading snapshots
Karl Wettin <[email protected]>
| Newsgroups | gmane.comp.java.prevayler |
|---|---|
| Message-ID | <[email protected]> |
25 jan 2011 kl. 02.57 skrev Justin T. Sampson: > 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. > I've conducted a bit of experiments on decoupling the object graph, store as several snapshot files and then recouple them after loading. It sure is as many times faster as I have cores. Recoupling takes virtually no time at all. Also there is a bit of overhead for the GC as I create extra empty instances with just identity set for each and every aggregation to an entity object. But is somewhat a hassle to implement it nice. All I have now is some terrible proof of concept code that is not implemented within Prevayler. Sort of busy the upcoming weeks, but I'll keep reporting my progress. Will try to do something within Prevayler that use some sort of strategy one has to implement that in conjunction with a bit of reflection and annotations takes care of all the decoupling, recoupling and snapshot factories. karl ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ To unsubscribe go to the end of this page: http://lists.sourceforge.net/lists/listinfo/prevayler-discussion _______________________________________________ "Databases in Memoriam" -- http://www.prevayler.org