On Thu, Jan 10, 2013 at 9:19 PM, Maciej Stachowiak m...@apple.com wrote:
On Jan 10, 2013, at 12:07 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jan 10, 2013 at 12:37 AM, Maciej Stachowiak m...@apple.com wrote:
I presume from your other comments that the goal of this work is
responsiveness,
On Jan 11, 2013, at 12:21 AM, Adam Barth aba...@webkit.org wrote:
On Thu, Jan 10, 2013 at 9:19 PM, Maciej Stachowiak m...@apple.com wrote:
On Jan 10, 2013, at 12:07 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jan 10, 2013 at 12:37 AM, Maciej Stachowiak m...@apple.com wrote:
I presume
Your comments here make me feel more positively towards this project. In
particular, I'm happy that:
- There actually will be meaningful testing.
- You're prepared to abandon this approach if it doesn't meet its perf goals
(presumably at minimum no regression to page load time or responsiveness
Parsing, especially JS parsing still takes a large amount of time on page
loading. We tried to improve the preload scanner by moving it into
anouther thread, but there was no gain (except some special cases).
Synchronization between threads is surprisingly (ridiculously) costly,
usually worth for
https://bugs.webkit.org/show_bug.cgi?id=63531
The work was done by Zoltan Horvath and Balazs Kelemen.
Regards,
Zoltan
Hi Zoltan,
I would be curious how you did the synchronization. I've had some luck
reducing synchronization costs before.
Was the patch ever uploaded anywhere?
-F
On
I presume from your other comments that the goal of this work is
responsiveness, rather than page load speed as such. I'm excited about the
potential to improve responsiveness during page loading.
One question: what tests are you planning to use to validate whether this
approach achieves its
When loading web pages we are very frequently in a situation where we
already have the source data (HTML text here but the same applies to
preloaded Javascript, CSS, images, ...) and know we are likely to need it
in soon, but can't actually utilize it for indeterminate time. This happens
because
The data Eric and Adam were using comes from a python library a few of us
have been developing called telemetry. Its basically a bunch of python
that lets us write performance tests against any browser that speaks the
inspector websocket protocol. We're using it a lot of should we
parallelize X
On Thu, Jan 10, 2013 at 8:37 AM, Maciej Stachowiak m...@apple.com wrote:
The reason I ask is that this sounds like a significant increase in
complexity, so we should be very confident that there is a real and major
benefit. One thing I wonder about is how common it is to have enough of the
Thanks everyone for your feedback. Detailed responses inline.
On Wed, Jan 9, 2013 at 9:41 PM, Filip Pizlo fpi...@apple.com wrote:
I think your biggest challenge will be ensuring that the latency of shoving
things to another core and then shoving them back will be smaller than the
latency of
On Jan 10, 2013, at 12:07 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Jan 10, 2013 at 12:37 AM, Maciej Stachowiak m...@apple.com wrote:
I presume from your other comments that the goal of this work is
responsiveness, rather than page load speed as such. I'm excited about the
Adam,
Thanks for your detailed reply. Seems like you guys have a pretty good plan in
place.
I hope this works and produces a performance improvement. That being said this
does look like a sufficiently complex work item that success is far from
guaranteed. So to play devil's advocate, what is
We're planning to move parts of the HTML Parser off of the main thread:
https://bugs.webkit.org/show_bug.cgi?id=106127
This is driven by our testing showing that HTML parsing on mobile is
be slow, and long (causing user-visible delays averaging 10 frames /
150ms).
On Wed, Jan 9, 2013 at 6:00 PM, Eric Seidel e...@webkit.org wrote:
We're planning to move parts of the HTML Parser off of the main thread:
https://bugs.webkit.org/show_bug.cgi?id=106127
This is driven by our testing showing that HTML parsing on mobile is
be slow, and long (causing
How will we ensure thread safety? Even at just the tokenizing level don't we
use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this
seems like it sould add a world of hurt.
I realise it's been a long time since I've worked on this so it's completely
possible that I'm
On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote:
How will we ensure thread safety? Even at just the tokenizing level don't we
use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this
seems like it sould add a world of hurt.
AtomicString is already
On Wed, Jan 9, 2013 at 7:07 PM, Eric Seidel e...@webkit.org wrote:
On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote:
How will we ensure thread safety? Even at just the tokenizing level
don't we use AtomicString? AtromicString isn't threadsafe wrt StringImpl
IIRC so this
On Wed, Jan 9, 2013 at 7:35 PM, Benjamin Poulain benja...@webkit.org wrote:
On Wed, Jan 9, 2013 at 7:07 PM, Eric Seidel e...@webkit.org wrote:
On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote:
How will we ensure thread safety? Even at just the tokenizing level
don't we use
I think your biggest challenge will be ensuring that the latency of shoving
things to another core and then shoving them back will be smaller than the
latency of processing those same things on the main thread.
For small documents, I expect concurrent tokenization to be a pure regression
On Wed, 9 Jan 2013, Eric Seidel wrote:
The core goal is to reduce latency -- to free up the main thread for
JavaScript and UI interaction -- which as you correctly note, cannot be
moved off of the main thread due to the single thread of execution
model of the web.
Parsing and (maybe to a
On Jan 9, 2013, at 10:04 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 9 Jan 2013, Eric Seidel wrote:
The core goal is to reduce latency -- to free up the main thread for
JavaScript and UI interaction -- which as you correctly note, cannot be
moved off of the main thread due to the single
21 matches
Mail list logo
