One thing to note is that pages, components and mixins are all mutating a document object. I can only assume that parallel rendering would require the DOM to be thread safe. My gut feel is that this would actually make rendering slower. On 4 Nov 2014 22:30, "Lance Java" <lance.j...@googlemail.com> wrote:
> I'd argue that there's "bigger fish to fry" than parallel rendering. > > What's all the "work" that will benefit from parallelisation? Because the > actual rendering itself is unlikely to see any significant time reduction > by multi threading. > > I'd actually wager a bet that the overhead of managing the threads > actually increases the rendering time. > > If it's the data retrieval that's taking the time, a cache or > multi-threaded data retrieval is probably a better place to focus your > efforts. > On 4 Nov 2014 21:52, "Alex Kotchnev" <akoch...@gmail.com> wrote: > >> Lance - I'm not saying that doing this would work out of the box or that >> it >> would be trivial , I understand that Tapestry as a framework has made >> choices that might make this difficult or impossible. Yet, it's a cool >> idea, in a way that a framework should be able to support its users (e.g. >> "ah, you want these rendered in parallel, fine, let me do this for you" >> kind of way). It seems like something that can be doable in Tapestry as >> well, I'm just not entirely sure how . It certainly seems possible to >> launch the "child threads" and have them have access to the parent >> thread's >> ThreadLocals. >> >> Cheers - >> >> On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <lance.j...@googlemail.com> >> wrote: >> >> > I'd say this is not a great idea. Tapestry assumes that rendering is >> all on >> > the same thread. The request and response (and other thread scoped >> > services) will be null on a non-request thread for instance. Also each >> > thread will have a separate hibernate session if using >> tapestry-hibernate >> > which will need to be cleaned up and won't share a level1 cache. >> > On 4 Nov 2014 19:57, "Alex Kotchnev" <akoch...@gmail.com> wrote: >> > >> > > I've been poking around Lift for the last few months and one of the >> > > interesting approaches it has is that it can mark "snippets" (roughly >> the >> > > equivalent of tapestry compoents) as "parallel" - what Lift does w/ >> > > snippets that are marked in parallel is that it fires up new threads >> for >> > > rendering those snippets and waits for all of them to complete before >> > > rendering the page / final output. >> > > >> > > Seems like a cool idea - knowing that Tapestry stores its state in >> > > ThreadLocal variables it seems that doing something similar wouldn't >> be >> > > trivial. Would something similar be possible - e.g. maybe the "child" >> > > threads can inherit the ThreadLocals of the thread that started them ? >> > > >> > > Anyway, it's just a curiosity question :-) After spending a >> considerable >> > > time learning and reading about Lift ( I liked some of the >> > non-traditional >> > > approaches that it takes to building web apps ) , my final conclusion >> was >> > > that Tapestry's component focused approach was superior ( I was quite >> > > surprised that despite being "view centric" Lift didn't have a way of >> > > coupling the snippet template and the snippet code into a cohesive >> > > component). >> > > >> > > Cheers - Alex K >> > > >> > >> >
