Hi, Sian! On Fri, Jul 18, 2008 at 1:16 PM, Sian January <[EMAIL PROTECTED]> wrote: > I think there needs to be some processing on the read stage, because the > length of some bands depends on the contents of previous bands so you won't > know how much to read unless you do some processing. But some things can be > done afterwards like sorting the constant pool, so there's definitely an > opportunity for parallelism there. Yes, a huge part of the non-dependent-from-I/O operations are already extracted in unpackProcess(). Of course, a part of computation should reside in read because of unknown bands' size, but if we manage to extract some more not related to reading computations from reading stage, it would worth a lot (see previous calculations).
Actually I see this is a gap in pack200 spec. I would really like to have the segment size in segment header to read the entire segment at once, but... *sigh*. There is a bunch of people interested in playing with parallelism in pack200: Andrew wanted to have some, I would enjoy seeing the parallel decompressor, Sergey Salishev wanted to hack around too :) So we need to discuss whether my approach to parallelism is ok, does someone object, or whatever else. Thanks, Aleksey.
