- From: Dimitri Glazkov <dglazkov@chromium.org>
- Date: Mon, 28 Nov 2011 09:18:13 -0800
- To: Roland Steiner <rolandsteiner@google.com>
- Cc: public-webapps <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>
On Thu, Nov 24, 2011 at 6:40 PM, Roland Steiner <rolandsteiner@google.com> wrote: > On Wed, Nov 23, 2011 at 08:05, Dimitri Glazkov <dglazkov@chromium.org> > wrote: >> >> Even if we attempt to separate the state of a decorator from the >> element and its document using an iframe- or worker-like machinery, >> we’ll still have similar issues of managing decorator instances that >> are no longer relevant, but don’t know that yet -- in addition to the >> performance costs of such high-isolation approach. > > I don't quite follow what you mean with the above - could you go into more > detail on this point? E.g., why would it be a problem if a worker-like > decorator that got detached sits around for a little while longer, doing > last timeouts and other stuff that no longer really matters? In case of total isolation, we totally could spec a clean shutdown process where the timers are cancelled and messages are dropped accordingly. > (FWIW, I'm also not convinced that it'd have to have high performance > overhead - in the best case it could be as little as just one more level of > indirection.) The startup time of a worker is non-trivial. Similarly, the shutdown won't be trivial. And the memory footprint of a worker isn't trivial either. If we're aiming for decorators to be fast and lean, we'll have to think of ways around those costs. :DG< > > Cheers, > - Roland >
Received on Monday, 28 November 2011 17:19:06 UTC