2011/1/14 Maciej Stachowiak
>
> On Jan 13, 2011, at 2:49 PM, Gavin Peters (蓋文彼德斯) wrote:
>
> Thanks everyone for your replies on link headers and rel types.
>
> Mike Belshe from Chrome team put together a spec for these as part of
> Server Hints for SPDY. His server h
Hi,
I tend to hit code which is often chromium-platform specific. It's hard to
know the appropriate "Platform" and "OS" fields for such a bug. For
instance, I am working on a small change to WebKit/chromium/src/WebKit.cpp.
It's not a Mac bug, its not a PC bug, its a Chromium bug.
Chromium is a
on selectively for ports that want it.
Mike
> Maybe there’s a good middle-ground, where PreloadScanner is run more often
> but still does the priority sorting?
>
>
>
> Joe
>
>
>
> *From:* webkit-dev-boun...@lists.webkit.org [mailto:
> webkit-dev-boun...@lists
On Thu, Jan 7, 2010 at 12:49 PM, Maciej Stachowiak wrote:
>
> On Jan 7, 2010, at 12:09 PM, Mike Belshe wrote:
>
> Hi -
>
> I've been working on SPDY, but I think I may have found a good performance
> win for HTTP. Specifically, if the PreloadScanner, which is respon
Hi -
I've been working on SPDY, but I think I may have found a good performance
win for HTTP. Specifically, if the PreloadScanner, which is responsible for
scanning ahead within an HTML document to find subresources, is throttled
today. The throttling is intentional and probably sometimes necess
On Tue, Dec 15, 2009 at 1:01 PM, Maciej Stachowiak wrote:
>
> On Dec 15, 2009, at 12:30 PM, Mike Belshe wrote:
>
> [+cc John Resig since he's using this as part of dromaeo]
>
> Overall, sounds like good progress.
>
> A couple of ideas:
>- can we make it so
run through the new harness.
>
> The most important harness change is greatly reducing the time between
> tests (as sugested by Mike Belshe) to avoid the negative impact of power
> management on many systems (both Mac and Windows), and which are most
> apparent for very fast browser
#x27;t be bundled and one which
can, then you may or may not suffer the extra RT.
This is really subtle stuff - web designers could think they are speeding
up their pages when they're slowing them down. The tools need to prevent
that. It can't be manual.
Mike
>
> -Steve
>
&
Alexander - when you do the testing on this, one case I'd really like to see
results on is this:
Page contains a resource bundle, and the bundle contains a bunch of
stylesheets, JS and other, but DOES NOT include one of the CSS files.
Immediately following the , put a reference to the
style sheet
On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe wrote:
> Overall, I think the general idea.
I meant to say "Overall I like the general idea"
>
> I'm concerned about the head-of-line blocking that it introduces. If an
> administrator poorly constructs the bundle,
Overall, I think the general idea.
I'm concerned about the head-of-line blocking that it introduces. If an
administrator poorly constructs the bundle, he could significantly hurt
perf. Instead of using gzip, you could use a framer which chunked items
before gzipping. This might be more trouble
On Tue, Jul 7, 2009 at 7:01 PM, Maciej Stachowiak wrote:
>
> On Jul 7, 2009, at 6:43 PM, Mike Belshe wrote:
>
>
>> (There are other benchmarks that use summation, for example iBench, though
>> I am not sure these are examples of excellent benchmarks. Any benchmark that
On Tue, Jul 7, 2009 at 5:08 PM, Maciej Stachowiak wrote:
>
> On Jul 7, 2009, at 4:19 PM, Peter Kasting wrote:
>
> For example, the framework could compute both sums _and_ geomeans, if
>> people thought both were valuable.
>>
>
> That's a plausible thing to do, but I think there's a downside: if
On Tue, Jul 7, 2009 at 4:45 PM, Maciej Stachowiak wrote:
>
> On Jul 7, 2009, at 4:28 PM, Mike Belshe wrote:
>
>
>> When SunSpider was first created, regexps were a small proportion of the
>> total execution in what were the fastest publicly available at the time.
>&g
On Tue, Jul 7, 2009 at 4:20 PM, Maciej Stachowiak wrote:
>
> On Jul 7, 2009, at 4:01 PM, Mike Belshe wrote:
>
>
>> I'd like benchmarks to:
>>a) have meaning even as browsers change over time
>>b) evolve. as new areas of JS (or whatever) become impo
On Tue, Jul 7, 2009 at 3:58 PM, Geoffrey Garen wrote:
> Are you saying that you did see Regex as being such a high percentage of
>> javascript code? If so, we're using very different mixes of content for our
>> tests.
>>
>
> I'm saying that I don't buy your claim that regular expression performa
On Tue, Jul 7, 2009 at 3:25 PM, Oliver Hunt wrote:
>
> On Jul 7, 2009, at 3:01 PM, Mike Belshe wrote:
>
> On Mon, Jul 6, 2009 at 10:11 AM, Geoffrey Garen wrote:
>
>> So, what you end up with is after a couple of years, the slowest test in
>>> the suite is the most
On Sat, Jul 4, 2009 at 3:27 PM, Maciej Stachowiak wrote:
>
> On Jul 4, 2009, at 11:47 AM, Mike Belshe wrote:
>
> I'd like to understand what's going to happen with SunSpider in the future.
> Here is a set of questions and criticisms. I'm interested in how these
As I said, we can argue the mix of tests forever, but it is not useful.
Yes, I would test using top-100 sites. In the future, if a benchmark
claims to have a representative mix, it should document why. Right?
Are you saying that you did see Regex as being such a high percentage of
javascript cod
On Mon, Jul 6, 2009 at 10:11 AM, Geoffrey Garen wrote:
> So, what you end up with is after a couple of years, the slowest test in
>> the suite is the most significant part of the score. Further, I'll predict
>> that the slowest test will most likely be the least relevant test, because
>> the tr
On Sat, Jul 4, 2009 at 3:27 PM, Maciej Stachowiak wrote:
>
> On Jul 4, 2009, at 11:47 AM, Mike Belshe wrote:
>
> I'd like to understand what's going to happen with SunSpider in the future.
> Here is a set of questions and criticisms. I'm interested in how these
I'd like to understand what's going to happen with SunSpider in the future.
Here is a set of questions and criticisms. I'm interested in how these can
be addressed.
There are 3 areas I'd like to see improved in
SunSpider, some of which we've discussed before:
#1: SunSpider is currently version
Hi, Haithem,
Both JSC and V8 running through the chromium tree, so you could try that.
If you run the "test_shell", its pretty much just a shell for driving the
webkit engine, and it works with both JS engines.
You can find more information here for how to build it:
http://dev.chromium.org/develop
Thanks Adam.
On Tue, Oct 14, 2008 at 5:47 AM, Adam Roben <[EMAIL PROTECTED]> wrote:
> On Oct 13, 2008, at 7:09 PM, Mike Belshe wrote:
>
> It took me a while to get my windows build going, so I thought I'd share
> what I learned:
>
>
> Thanks, Mike! This kind o
It took me a while to get my windows build going, so I thought I'd share
what I learned:
1) I had to completely start over with cygwin. I uninstalled and
reinstalled using the cygwin-downloader from here:
http://webkit.org/building/tools.html
2) Several components were missing from cygwin:
-
Another devil's advocate argument:
Let's fast-forward for a year or two, and the hires timer exists in some
form. Do we need to offer any protections against CPU spinning?
What if one browser (say the dominant market-leading browser at the time)
implements this with timers that have a 15ms granu
I'm not opposed to any of this; and the new API is definitely nicer. I'll
bring up a devil's advocate point. One thing I hate is the Microsoft-style
smorgasboard of APIs. When you want to start a timer, you have 6 to choose
from, and I hope we can avoid similar problems in the DOM. If keeping t
On Wed, Oct 1, 2008 at 5:03 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Oct 1, 2008, at 4:48 PM, Peter Kasting wrote:
>
> On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
>> Do we have any measurements of the performance benefit?
>>
>
> Copying verbatim Fe
On Wed, Oct 1, 2008 at 4:30 PM, Peter Kasting <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 1, 2008 at 4:03 PM, Mike Belshe <[EMAIL PROTECTED]> wrote:
>
>> Also - Chrome currently taps into RefCountable and adds Peerable across
>> any RefCountable object, whether it needs
Maciej -
Thanks for taking a look at this!
First, a little history on this topic. In Chrome, we call this cached
pointer interface "Peerable". Originally, when we built Peerable, it was
not strictly for performance. At that time we hoped it would help us with
breaking of circular references (we
If you're going to propose a new API designed for hi-res timers, it ought to
use units of microseconds instead of milliseconds.
Mike
On Tue, Sep 30, 2008 at 7:32 PM, Justin Haygood <[EMAIL PROTECTED]>wrote:
>
> http://blog.justinhaygood.com/2008/09/30/proposed-high-resolution-timer-api/
>
> It's
I think you've already seen this, but in case you haven't - here is the bug
where I've been tracking this. Every report I've seen related to minimum
timers is referenced in here.
http://code.google.com/p/chromium/issues/detail?id=792
I think the evidence is pretty compelling that <10ms and >1m
Thanks everyone for the feedback and ideas. Sounds like we're converging.
Maciej - I'll volunteer to do the work in the webkit tree to reduce the
existing timer and testing that is deemed necessary (actually, I think this
is mostly a testing task; the code change is trivial). I think the test I
s
On Tue, Sep 30, 2008 at 3:45 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Sep 30, 2008, at 3:06 PM, Mike Belshe wrote:
>
> Subjective note:
>>
>> I'm much more worried about sites spinning the CPU accidentally (e.g. they
>> used setTimeout(
Subjective note:
I'm much more worried about sites spinning the CPU accidentally (e.g. they
used setTimeout(0) somewhere by accident) than I am about frame rates on
games. Using the clock as your frame rate is super buggy, and sites need to
know better. It won't work now and it won't work going
>
>
> BTW - if the primary concern is not spinning the CPU, we could just drop
>> the throttle down to 2 or 3ms, and the CPU will be largely idle on most
>> machines. In a few years, with faster processors, we'll be able to drop to
>> 1ms and still have largely idle CPU.
>>
>> Would 3ms be viable
d.
As for keeping the fan off - if we could keep the CPU idle a 3ms minimum
timeout loop does that resolve your concern?
Mike
2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>
>
> Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а):
>
> Thanks - I did see that bug. Intent
/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>
>
> Sep 30, 2008, в 6:37 PM, Mike Belshe написал(а):
>
> Thanks for the concrete examples, Dave! I tested all 3 of these, and
>> haven't yet found any problems. But I don't have specific URLs. I also
>> looked
at kind of headache?
> A new API will let Web apps get the performance they need while avoiding
> compatibility problems.
>
> dave
>
> On Sep 29, 2008, at 10:06 PM, Maciej Stachowiak wrote:
>
>
> On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote:
>
> Hi,
> One of the d
Hi, Maciej,
Thanks for the response.
Comments below
On Mon, Sep 29, 2008 at 8:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Sep 29, 2008, at 7:26 PM, Mike Belshe wrote:
>
> Hi,
> One of the differences between Chrome and Safari is that Chrome sets the
> se
Hi,
One of the differences between Chrome and Safari is that Chrome sets the
setTimeout clamp to 1ms as opposed to 10ms. This means that if the
application writer requests a timer of less than 10ms, Chrome will allow it,
whereas Safari will clamp the minimum timeout to 10ms. The reason we did
thi
I'm trying to create a changelog from windows without success.
I have read the instructions here:
http://webkit.org/coding/contributing.html
When I run the script, I produces this:
> ../../WebKitTools/Scripts/prepare-ChangeLog
Running status to find changed, added, or removed files.
Reviewing
42 matches
Mail list logo
