Re: [webkit-dev] setTimeout as browser speed throttle
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote: In short, our architecture makes me more willing to take risks with setTimeout clamping than I would be otherwise. This is a good thing I think because we have the opportunity to test this out and get more data without risking as much. I guess I don't expect it to make a huge difference but if you would like to test a value higher than 1ms but less than 10ms in live code I'd certainly love to hear the results. When we have that data, we'll share it. I'm not sure when that will happen. Are you planning to test a specific alternate interval? I don't know what Mike is planning to do exactly. I think we just disagree here. In my opinion since setTimeout clamping is so varied across browsers and even varies in Firefox depending on whether or not a flash animation is going, the expectation of consistent clamping has to be low. Or at least it has to be the case that it doesn't matter much if different browsers have different clamping values in practice. So I think there is room to do interesting things related to different power management states. Anyways, I'm just telling you what we are considering doing. I'm not really talking about developer expectation here so much as the possibility that, if indeed a lower clamp is a performance improvement for real sites, then said sites would noticeably slow down the moment you unplug. As a user I would find that surprising and weird. My laptop slows down considerably when I unplug it because of power saving settings. I don't find that too unusual. Mine doesn't. Instead it slews the CPU clockspeed based on workload and shuts down components (including the CPU) whenver possible. Get a Mac. :-) In all seriousness, I see your point for Windows machines. User expectations for the unplugged state may be lower. Yeah, OK ;-) (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote: As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think this data point is meaningful. This wasn't a comparison of the handling of different browsers. I was saying that this is a rather drastic measure that users have to take in order to avoid errant javascripts from eating away battery storage. It might make sense to allow users to disable timers separately from disabling javascript in total. In that way it might also encourage authors to use timers appropriately when they might not be able to count on timers being enabled always (using them only when appropriate then). Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Oct 3, 2008, at 12:21 PM, Rob Burns wrote: On Oct 2, 2008, at 6:28 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote: As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think this data point is meaningful. This wasn't a comparison of the handling of different browsers. I was saying that this is a rather drastic measure that users have to take in order to avoid errant javascripts from eating away battery storage. It might make sense to allow users to disable timers separately from disabling javascript in total. In that way it might also encourage authors to use timers appropriately when they might not be able to count on timers being enabled always (using them only when appropriate then). Since I fear the logic here has been lost let me try to summarize what I'm trying to say on this topic. • setTimeout gets used in cases where it is not always the best solution for authors: i.e., using for polling when a specified event would be a better way to provide interactivity • setTimeout is probably most often tested on IE with a clamp of 15ms and any author testing elsewhere does not focus on power consumption issues • for these cases where it is not being used correctly, a user of Chrome (with a 1ms clamp) will experience 15X processor use over a user of IE (with 15ms clamp) • the 15x processor utilization will result in an accelerated power drain on mobile devices running Chrome compared to those running IE • most users will not diagnose the issue down to a specific tab or a specific page, but may at times identify the browser or the platform as the problem My approach to dealing with this is to leave any number of pages I desire open in Safari my main browser and avoid flash and javascript entirely there. If a page requires javascript, I fire up Shira or Opera or another browser with javascript and flash enabled and make sure I quit the application before I go on battery or immediately after viewing the page. This gives me immensely more battery life than I would otherwise have given my usage patterns (like having a second or even a third battery). Take care, Rob___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
HI Darin, On Oct 3, 2008, at 1:22 PM, Darin Fisher wrote: On Fri, Oct 3, 2008 at 3:10 AM, Rob Burns [EMAIL PROTECTED] wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). Take care, Rob It's a good question. I suspect though that it could break sites. Imagine a calendar application that wishes to periodically wake up to see if it should put up an alert to notify you of an upcoming event. Such a feature probably requires the ability to run a timer. Yes, understood. But this example also requires javascript enabled. If a user disables javascript this web app will not work either. I'm suggesting WebKit could allow more finegrained control by allowing javascript enabled, but timers disabled. Also this example illustrates how an author of such a calendar web app may use setTimeout as a polling device rather than using an event- based approach where the application simply sets event timers for those alerts. By allowing greater control over disabling setTimeout, the authoring community will be forced to learn about better approaches to authoring such a web app. Obviously this stuff won't happen tomorrow, but we have to take a long view of it from time to time and think about what we can do to get there. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Oct 3, 2008, at 3:10 AM, Rob Burns wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). There are web apps that a user may legitimately want to continue to work in the background. One obvious example is a web-based audio player, although in that case it would be a plugin or audio element continuing to do work. Still, if you're going to allow plugins and media elements to continue, you may as well allow timers. Other sites update their title on a timer in a way that is useful for a background tab. For example, GMail updates the unread count, which is quite useful on a background tab label. Given these kinds of examples, I think pausing anything in a background tab would not be a good choice; if that kind of functionality were on offer it should be a more explicit user gesture. All in all, I think we shouldn't overreact on the timer issue. Sites that consume egregious amounts of computing resources, whether through timers or otherwise, are the minority, and so long as they suck in all browsers and not just some, users will blame the site and it will be pressured to change. So really (in my opinion), matching or beating the CPU consumption of other browsers is the target, and we shouldn't go crazy with novel ways to restrict timers or anything else. Just avoid looking broken on sites that were only tested in IE or Firefox. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
HI Maciej, On Oct 3, 2008, at 3:16 PM, Maciej Stachowiak wrote: On Oct 3, 2008, at 3:10 AM, Rob Burns wrote: Hi Darin, On Oct 3, 2008, at 9:37 AM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Yeah, that's the trade off. Close the offending tab or let it run, but more slowly. Another option, would be to halt timers for all unexposed tabs (i.e., tabs in windows that are not the frontmost tab). Are there use-cases or sites that would break with such behavior? The reason I raise this option is that the loaded page represents important state to the user, but when it is buried on a window, it is probably not necessary for it to be actively responding to timer callbacks. Closing the tab saves battery life, but burying the tab behind another tab would be preferable for the user (a mobile user that may not be online when that important state represented by the page loaded in the tab is sought again). There are web apps that a user may legitimately want to continue to work in the background. One obvious example is a web-based audio player, although in that case it would be a plugin or audio element continuing to do work. Still, if you're going to allow plugins and media elements to continue, you may as well allow timers. Other sites update their title on a timer in a way that is useful for a background tab. For example, GMail updates the unread count, which is quite useful on a background tab label. Given these kinds of examples, I think pausing anything in a background tab would not be a good choice; if that kind of functionality were on offer it should be a more explicit user gesture. I agree with that. To me burying a tab is an explicit and often deliberate user gesture. It would take novice users little time to adjust to the pausing of buried tabs (pausing with respect to all processing: plugins, animated images, and javascript for example). If audio is playing and it pauses because the tab is buried, the user will quickly come to understand that the tab needs to be exposed and to switch to a new window to create the new tab. The audio still plays in a background window, just not in a background tab. Until tab management gets up to speed, that would be a prudent approach anyway. All in all, I think we shouldn't overreact on the timer issue. Sites that consume egregious amounts of computing resources, whether through timers or otherwise, are the minority, and so long as they suck in all browsers and not just some, users will blame the site and it will be pressured to change. So really (in my opinion), matching or beating the CPU consumption of other browsers is the target, and we shouldn't go crazy with novel ways to restrict timers or anything else. Just avoid looking broken on sites that were only tested in IE or Firefox. My experience is that the problem is much more of a problem (but I'm mobile a lot). Adding a new highres timer is a good step, but if that's already available, then providing setTimeout a 15 fold difference in clamps between WebKit and IE (the primary test browser) will really exacerbate the problem (perhaps as much as a significant percentage loss in battery-charge-life). As for trying to avoid restricting timers that merely leads to restricting javascript in total. The only reason I would ever want to turn off javascript is to control poorly authored timers (and similar poorly authored plugins and plugin authoring). So I lose all javascript support simply to avoid timers, where I would prefer to lose the timer capabilities and still have the remaining javascript or maintain all javascript and lose timers for buried tabs. If we assume the new highres API will not be abused the way setTimeout is
Re: [webkit-dev] setTimeout as browser speed throttle
On 03/10/2008, at 14:16, Maciej Stachowiak wrote: [...] Other sites update their title on a timer in a way that is useful for a background tab. For example, GMail updates the unread count, which is quite useful on a background tab label. [...] Maybe the new Timer API should be extended with an option for: should this timer be executed when the page is hidden in a background tab. Animation timers would then specify no, thereby reducing amount of cpu/ battery consumed. GMail could specify yes: low-overhead update of the unread count in background. It would make sense to have the default to be false, and to be the last parameter. - Peter Speck ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Thu, Oct 2, 2008 at 10:36 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Are you planning to test a specific alternate interval? I believe Mike is raising the Chromium clamp to 4 ms. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Oct 2, 2008, at 6:01 AM, Linus Upson wrote: My impression from your remarks was that you thought 1ms is working fine 1ms is definitely not working fine for me. I've started reading the Washington Post since NYT makes my fan whir. As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. I wonder if in addition to a highres timer, we shouldn't also be considering other event driven APIs that could largely eliminate the use of timers from most sites. Take care, Rob ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Thu, Oct 2, 2008 at 3:23 AM, Rob Burns [EMAIL PROTECTED] wrote: As another drastic anecdotal step, I've turned off javascript on Safari (my main browser) and turn to other browsers when I find a site that requires javascript. If I don't do that, I find my Macbook Air battery eaten away in under an hour just because I left pages open that use setTimeout inappropriately. Safari doesn't have a lower setTimeout() cap than Firefox, so I don't think this data point is meaningful. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Wed, Oct 1, 2008 at 5:26 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 1, 2008, at 5:03 PM, Darin Fisher wrote: On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 1, 2008, at 1:24 AM, David Hyatt wrote: On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote: I can appreciate that you aren't interested in revisiting this problem after having resolved it finally by adding the clamp. I believe you when you say you had compelling evidence too. We are interested in revisiting the problem or we wouldn't be suggesting a new high resolution timer API. I'm with Hyatt. The reason we are having this thread is precisely to revisit the problem. Good to hear. From what you wrote, I thought you were disinterested in considering lower clamp values for setTimeout, and that is what I was referring to. (I knew you supported a high-res timer API.) From what you say below, however, I see that you are interested in lowering the clamp value. Sorry for misunderstanding. I'm interested in finding out whether there is a value lower than 10ms but higher than 1ms that is (a) safe and (b) beneficial for performance on real sites. It seems clear to me that 1ms is not safe. My impression from your remarks was that you thought 1ms is working fine, and that passively waiting to get more feedback from Chrome users was an ok way to confirm that it is fine. If that's not what you meant, then my apologies for misinterpreting. If it is what you meant, then I continue to respectfully disagree on both fronts. I am indeed interested in passive feedback from users and web developers. But I'm also interested in the anonymous, opt-in aggregate data collection that we can perform ourselves (as Linus mentioned). The challenge is to find a way to be confident in selecting a clamp value. Feedback from users seems like an important metric but it is not the only metric. I don't know how clear I was in the previous email, but basically it can take a lot of time before you see problems. What happens is a site makes a change, screws up and puts in an unintentional setTimeout loop, and then they pwn the CPU of a browser with no clamp. They don't discover it because every browser has a pretty high clamp. When we had these issues, they'd basically crop up one site at a time every so often. The good news is that usually the sites would fix the problems, but the bad news is it could take a while, and angry users would be switching to Firefox. That is what I was alluding to when I said it took us 3.5 years to first realize we had to add the clamp. The problems come and go, but they are consistently a problem, and it can take a while to realize it. Yup, I can totally see that happening. This is why I highlighted our architecture, which helps more squarely place blame on misbehaving sites. That should help developers and users more easily see who to blame, which should help these issues get more visibility and be resolved more quickly. I may be wrong, but I'm curious to find out. This seems implausible to me. When a site misrenders, it is obvious which site is misbehaving, but users still usually blame the browser, not the site. I think that users often only notice high CPU usage after it has been occurring for a while. At that point it is frequently not well correlated to recent browsing activity. You might have already opened other tabs. Maybe it was even a background tab that started acting up. In a single process browser, a user just sees the browser process consuming CPU. In Chrome, they see a particular tab (or maybe a set of tabs) consuming CPU. So they can diagnose the problem and point fingers more easily. In short, our architecture makes me more willing to take risks with setTimeout clamping than I would be otherwise. This is a good thing I think because we have the opportunity to test this out and get more data without risking as much. Laptops on battery power are not an issue since we wouldn't want to enable high-res timers on those systems. timeBeginPeriod(1) being too costly there. There's no such thing as timeBeginPeriod on Mac or Linux. And I believe the timeBeginPeriod problem is solvable on Windows (there is no need to have it on all the time). Overall I think it would be poor form if site behavior changed depending on whether I was plugged into a power cable. Yeah, I realize that this is a Windows only API. I think we just disagree here. In my opinion since setTimeout clamping is so varied across browsers and even varies in Firefox depending on whether or not a flash animation is going, the expectation of consistent clamping has to be low. Or at least it has to be the case that it doesn't matter much if different browsers have different clamping values in practice. So I think there is room to do interesting things related to different power management states. Anyways, I'm just telling you
Re: [webkit-dev] setTimeout as browser speed throttle
On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote: I am indeed interested in passive feedback from users and web developers. But I'm also interested in the anonymous, opt-in aggregate data collection that we can perform ourselves (as Linus mentioned). The challenge is to find a way to be confident in selecting a clamp value. Feedback from users seems like an important metric but it is not the only metric. I think testing on already the known problem sites with different clamp values, and hunting for more problem sites in some active way, are probably the most valuable additional data gathering that we can do. I think that users often only notice high CPU usage after it has been occurring for a while. At that point it is frequently not well correlated to recent browsing activity. You might have already opened other tabs. Maybe it was even a background tab that started acting up. In a single process browser, a user just sees the browser process consuming CPU. In Chrome, they see a particular tab (or maybe a set of tabs) consuming CPU. So they can diagnose the problem and point fingers more easily. Our experience is that users often do notice what site is inadvertantly causing high CPU, because they file bug reports mentioning the URL, and pointing out that it doesn't cause the same problem in Firefox. Now, it might be that there are even more problems where the user does not identify the problem site and does not file a bug; I have no way to rule out that possibility. In short, our architecture makes me more willing to take risks with setTimeout clamping than I would be otherwise. This is a good thing I think because we have the opportunity to test this out and get more data without risking as much. I guess I don't expect it to make a huge difference but if you would like to test a value higher than 1ms but less than 10ms in live code I'd certainly love to hear the results. Laptops on battery power are not an issue since we wouldn't want to enable high-res timers on those systems. timeBeginPeriod(1) being too costly there. There's no such thing as timeBeginPeriod on Mac or Linux. And I believe the timeBeginPeriod problem is solvable on Windows (there is no need to have it on all the time). Overall I think it would be poor form if site behavior changed depending on whether I was plugged into a power cable. Yeah, I realize that this is a Windows only API. The reason that I mention this is that on Mac and Linux systems, there's no special power-wasting system call to enable high-res timers. I think we just disagree here. In my opinion since setTimeout clamping is so varied across browsers and even varies in Firefox depending on whether or not a flash animation is going, the expectation of consistent clamping has to be low. Or at least it has to be the case that it doesn't matter much if different browsers have different clamping values in practice. So I think there is room to do interesting things related to different power management states. Anyways, I'm just telling you what we are considering doing. I'm not really talking about developer expectation here so much as the possibility that, if indeed a lower clamp is a performance improvement for real sites, then said sites would noticeably slow down the moment you unplug. As a user I would find that surprising and weird. (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Oct 2, 2008, at 10:09 PM, Darin Fisher wrote: On Thu, Oct 2, 2008 at 9:58 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote: In short, our architecture makes me more willing to take risks with setTimeout clamping than I would be otherwise. This is a good thing I think because we have the opportunity to test this out and get more data without risking as much. I guess I don't expect it to make a huge difference but if you would like to test a value higher than 1ms but less than 10ms in live code I'd certainly love to hear the results. When we have that data, we'll share it. I'm not sure when that will happen. Are you planning to test a specific alternate interval? I think we just disagree here. In my opinion since setTimeout clamping is so varied across browsers and even varies in Firefox depending on whether or not a flash animation is going, the expectation of consistent clamping has to be low. Or at least it has to be the case that it doesn't matter much if different browsers have different clamping values in practice. So I think there is room to do interesting things related to different power management states. Anyways, I'm just telling you what we are considering doing. I'm not really talking about developer expectation here so much as the possibility that, if indeed a lower clamp is a performance improvement for real sites, then said sites would noticeably slow down the moment you unplug. As a user I would find that surprising and weird. My laptop slows down considerably when I unplug it because of power saving settings. I don't find that too unusual. Mine doesn't. Instead it slews the CPU clockspeed based on workload and shuts down components (including the CPU) whenver possible. Get a Mac. :-) In all seriousness, I see your point for Windows machines. User expectations for the unplugged state may be lower. (I don't understand your comment about not having to have it on all the time. Surely if a page is asking for a fast setTimeout repeatedly, it would be on all the time.) My understanding is that timeBeinPeriod(1) is currently on all the time in Chrome, even when no short-delay timers are currently pending, thus leading to constant greater power consumption. But there is no need for it to be on when there are not fast timers pending. See WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically better approach than switching based on power management state. Feedback welcome, though, and perhaps you will still come to a different conclusion. I think that is a good idea too, but it doesn't help when a fast setInterval is active. That is true. With the webkit.org version of SharedTimerWin, though, you can at least close the problematic tab when you hear your fan spin up and stop suffering any power drain. It may be that running slower is a better option. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
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 1ms is a better value. Mike On Tue, Sep 30, 2008 at 11:55 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 10:36 PM, Darin Fisher wrote: On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: ... 2) Consider making WebKit's default minimum timer limit lower - something like 3ms-5ms. I don't know what we would do to verify that this is safe enough or who would do the work. Maybe Hyatt? We are in the process of verifying this now ;-) Our eyes and ears are open (have been) for bug reports related to this. Right now, we are happy to be trying something radical. In the absence of problem reports, when do we declare success? Based on what Peter said, it sounds like there has been at least one problem report. There was at least one more vague report made informally in John Resig's blog comments. Maybe we need to start by agreeing what counts as absence of problem reports. However, by way of comparison, we added a 10ms clamp three and a half years after the first Safari beta was released to the public, as it took about that long to get enough bug reports to convince us that we had to do it for compatibility. Given that, I think we may want to find some more active way to look for potential problems and potential benefits. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Tue, Sep 30, 2008 at 11:55 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 10:36 PM, Darin Fisher wrote: On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: ... 2) Consider making WebKit's default minimum timer limit lower - something like 3ms-5ms. I don't know what we would do to verify that this is safe enough or who would do the work. Maybe Hyatt? We are in the process of verifying this now ;-) Our eyes and ears are open (have been) for bug reports related to this. Right now, we are happy to be trying something radical. In the absence of problem reports, when do we declare success? Based on what Peter said, it sounds like there has been at least one problem report. There was at least one more vague report made informally in John Resig's blog comments. Maybe we need to start by agreeing what counts as absence of problem reports. However, by way of comparison, we added a 10ms clamp three and a half years after the first Safari beta was released to the public, as it took about that long to get enough bug reports to convince us that we had to do it for compatibility. Given that, I think we may want to find some more active way to look for potential problems and potential benefits. Regards, Maciej I can appreciate that you aren't interested in revisiting this problem after having resolved it finally by adding the clamp. I believe you when you say you had compelling evidence too. My point was just that we wanted to feel the pain ourselves before going a similar route. We have yet to feel the pain substantially, and so it is interesting to keep going, gathering more data points. (Our architecture is designed to allow users to see that it is a particular website that is misbehaving and so we have a lot of opportunity I think to raise the visibility of things like this and to at least gather more data.) -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
We can use the histogram facility in chrome to collect data from a dev channel release. It should only take a few weeks to get good data. What exactly do we want to measure to settle on a value? Linus On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 1, 2008, at 1:24 AM, David Hyatt wrote: On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote: I can appreciate that you aren't interested in revisiting this problem after having resolved it finally by adding the clamp. I believe you when you say you had compelling evidence too. We are interested in revisiting the problem or we wouldn't be suggesting a new high resolution timer API. I'm with Hyatt. The reason we are having this thread is precisely to revisit the problem. I don't know how clear I was in the previous email, but basically it can take a lot of time before you see problems. What happens is a site makes a change, screws up and puts in an unintentional setTimeout loop, and then they pwn the CPU of a browser with no clamp. They don't discover it because every browser has a pretty high clamp. When we had these issues, they'd basically crop up one site at a time every so often. The good news is that usually the sites would fix the problems, but the bad news is it could take a while, and angry users would be switching to Firefox. That is what I was alluding to when I said it took us 3.5 years to first realize we had to add the clamp. The problems come and go, but they are consistently a problem, and it can take a while to realize it. However, the bug Mike cited seems to mention problems with the 1ms limit on some real sites: http://code.google.com/p/chromium/issues/detail?id=792. At least 5 sites are mentioned, including nytimes. I think we are converging on some good solutions (somewhat lower basic clamp, new highres API) and I regret if this thread has felt hostile to anyone. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Wed, Oct 1, 2008 at 2:34 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 1, 2008, at 1:24 AM, David Hyatt wrote: On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote: I can appreciate that you aren't interested in revisiting this problem after having resolved it finally by adding the clamp. I believe you when you say you had compelling evidence too. We are interested in revisiting the problem or we wouldn't be suggesting a new high resolution timer API. I'm with Hyatt. The reason we are having this thread is precisely to revisit the problem. Good to hear. From what you wrote, I thought you were disinterested in considering lower clamp values for setTimeout, and that is what I was referring to. (I knew you supported a high-res timer API.) From what you say below, however, I see that you are interested in lowering the clamp value. Sorry for misunderstanding. I don't know how clear I was in the previous email, but basically it can take a lot of time before you see problems. What happens is a site makes a change, screws up and puts in an unintentional setTimeout loop, and then they pwn the CPU of a browser with no clamp. They don't discover it because every browser has a pretty high clamp. When we had these issues, they'd basically crop up one site at a time every so often. The good news is that usually the sites would fix the problems, but the bad news is it could take a while, and angry users would be switching to Firefox. That is what I was alluding to when I said it took us 3.5 years to first realize we had to add the clamp. The problems come and go, but they are consistently a problem, and it can take a while to realize it. Yup, I can totally see that happening. This is why I highlighted our architecture, which helps more squarely place blame on misbehaving sites. That should help developers and users more easily see who to blame, which should help these issues get more visibility and be resolved more quickly. I may be wrong, but I'm curious to find out. Laptops on battery power are not an issue since we wouldn't want to enable high-res timers on those systems. timeBeginPeriod(1) being too costly there. -Darin However, the bug Mike cited seems to mention problems with the 1ms limit on some real sites: http://code.google.com/p/chromium/issues/detail?id=792.http://code.google.com/p/chromium/issues/detail?id=792 At least 5 sites are mentioned, including nytimes. I think we are converging on some good solutions (somewhat lower basic clamp, new highres API) and I regret if this thread has felt hostile to anyone. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
My impression from your remarks was that you thought 1ms is working fine 1ms is definitely not working fine for me. I've started reading the Washington Post since NYT makes my fan whir. Linus ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
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 through the webkit bugs database as much as I could, and could not locate them. 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 in your eyes? Mike On Mon, Sep 29, 2008 at 8:58 PM, David Hyatt [EMAIL PROTECTED] wrote: We encountered 100% CPU spins on amazon.com, orbitz.com, mapquest.com, among others (looking through Radar histories). This was pre-clamp. Web sites make this mistake because they don't know any better, and it works fine in IE. It is a mistake these sites will continue to make, and Chrome is the only browser that will be susceptible. Being different from IE here is not a good thing. You will end up having to evangelize sites over and over to fix 100% CPU spins that occur only in your browser. Do you really want that 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 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 this was to minimize browser delays when running graphical javascript applications. This has been a concern for some, so I wanted to bring it up here and get an open discussion going. My hope is to lower or remove the clamp over time. To demonstrate the benefit, here is one test case which benefits from removing the setTimeout clamp. Chrome gets about a ~4x performance boost by reducing the setTimeout clamp. This programming pattern in javascript is very common. http://www.belshe.com/test/sort/sort.htmlhttp://www.belshe.com/test/sort/sort.html One counter argument brought up is a claim that all other browsers use a 10ms clamp, and this might cause incompatibilities. However, it turns out that browsers already use widely varying values. I believe all major browsers (besides Chrome) have a minimum of either 10ms or 15.6ms. I don't think this is widely varying. We also really haven't seen any incompatibilities due to this change. It is true that having a lower clamp can provide an easy way for web developers to accidentally spin the CPU, and we have seen one high-profile instance of this. But of course spinning the CPU can be done in javascript all by itself :-) The kinds of problems we are concerned about are of three forms: 1) Animations that run faster than intended by the author (it's true that 10ms vs 16ms floors will give slight differences in speed, but not nearly as much so as 10ms vs no delay). 2) Burning CPU and battery on pages where the author did not expect this to happen, and had not seen it on the browsers he or she has tested with. 3) Possibly slowing things dow if a page is using a 0-delay timer to poll for completion of network activity. The popular JavaScript library jQuery does this to detect when all stylesheets have loaded. Lack of clamping could actually slow down the loading it is intended to wait for. 4) Future content that is authored in one of Safari or Chrome that depends on timing of 0-delay timers will have different behavior in the other. Thus, we get less compatibility benefit for WebKit-based browsers through cross-testing. The fact that you say you have seen one high-profile instance doesn't sound to me like there are no incompatibilities. It sounds like there are some, and you have encountered at least one of them. Points 1 and 2 are what made us add the timer minimum in the first place, as documented in WebKit's SVN history and ChangeLogs. We originally did not have one, and added it for compatibility with other browsers. Currently Chrome gets an advantage on some benchmarks by accepting this compatibility risk. This leads to misleading performance comparisons, in much the same way as firing the load event before images are loaded would. Here is a summary of the minimum timeout for existing browsers (you can test your browser with this page: http://www.belshe.com/test/timers.html )http://www.belshe.com/test/timers.html Safari for the mac: 10ms Safari for windows:15.6ms Firefox: 10ms or 15.6ms, depending on whether or not Flash is running on the system IE : 15.6ms Chrome: 1ms (future - remove the clamp?) So here are a couple of options: 1) Remove or lower the clamp so that javascript
Re: [webkit-dev] setTimeout as browser speed throttle
When I use setTimeouts, often the event has already occurred. So rather than clamping, I'd suggest increasing the timeout up to 10ms rather than clamping it at the start. Thus, if I specify 0, an immediate check would occur, then move it up each time, maybe 1, 5, 10 would be optimum. On Monday, September 29, 2008, at 10:58PM, David Hyatt [EMAIL PROTECTED] wrote: We encountered 100% CPU spins on amazon.com, orbitz.com, mapquest.com, among others (looking through Radar histories). This was pre-clamp. Web sites make this mistake because they don't know any better, and it works fine in IE. It is a mistake these sites will continue to make, and Chrome is the only browser that will be susceptible. Being different from IE here is not a good thing. You will end up having to evangelize sites over and over to fix 100% CPU spins that occur only in your browser. Do you really want that 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 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 this was to minimize browser delays when running graphical javascript applications. This has been a concern for some, so I wanted to bring it up here and get an open discussion going. My hope is to lower or remove the clamp over time. To demonstrate the benefit, here is one test case which benefits from removing the setTimeout clamp. Chrome gets about a ~4x performance boost by reducing the setTimeout clamp. This programming pattern in javascript is very common. http://www.belshe.com/test/sort/sort.html One counter argument brought up is a claim that all other browsers use a 10ms clamp, and this might cause incompatibilities. However, it turns out that browsers already use widely varying values. I believe all major browsers (besides Chrome) have a minimum of either 10ms or 15.6ms. I don't think this is widely varying. We also really haven't seen any incompatibilities due to this change. It is true that having a lower clamp can provide an easy way for web developers to accidentally spin the CPU, and we have seen one high-profile instance of this. But of course spinning the CPU can be done in javascript all by itself :-) The kinds of problems we are concerned about are of three forms: 1) Animations that run faster than intended by the author (it's true that 10ms vs 16ms floors will give slight differences in speed, but not nearly as much so as 10ms vs no delay). 2) Burning CPU and battery on pages where the author did not expect this to happen, and had not seen it on the browsers he or she has tested with. 3) Possibly slowing things dow if a page is using a 0-delay timer to poll for completion of network activity. The popular JavaScript library jQuery does this to detect when all stylesheets have loaded. Lack of clamping could actually slow down the loading it is intended to wait for. 4) Future content that is authored in one of Safari or Chrome that depends on timing of 0-delay timers will have different behavior in the other. Thus, we get less compatibility benefit for WebKit-based browsers through cross-testing. The fact that you say you have seen one high-profile instance doesn't sound to me like there are no incompatibilities. It sounds like there are some, and you have encountered at least one of them. Points 1 and 2 are what made us add the timer minimum in the first place, as documented in WebKit's SVN history and ChangeLogs. We originally did not have one, and added it for compatibility with other browsers. Currently Chrome gets an advantage on some benchmarks by accepting this compatibility risk. This leads to misleading performance comparisons, in much the same way as firing the load event before images are loaded would. Here is a summary of the minimum timeout for existing browsers (you can test your browser with this page: http://www.belshe.com/test/timers.html ) Safari for the mac: 10ms Safari for windows:15.6ms Firefox: 10ms or 15.6ms, depending on whether or not Flash is running on the system IE : 15.6ms Chrome: 1ms (future - remove the clamp?) So here are a couple of options: 1) Remove or lower the clamp so that javascript apps can run substantially faster. 2) Keep the clamp and let them run slowly :-) Thoughts? It would be great to see Safari and Chrome use the same clamping values. Or there is option 3: 3) Restore the
Re: [webkit-dev] setTimeout as browser speed throttle
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 through the webkit bugs database as much as I could, and could not locate them. One example is https://bugs.webkit.org/show_bug.cgi?id=6998. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Thanks - I did see that bug. Intentionally spinning the CPU vis setTimeout(,0) is not a problem if it is what the application intended. In the bug you mention, it mentions mapquest as a potential site with this issue. But I can't reproduce that, and there are no specific URLs. Mike 2008/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 through the webkit bugs database as much as I could, and could not locate them. One example is https://bugs.webkit.org/show_bug.cgi?id=6998. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а): Thanks - I did see that bug. Intentionally spinning the CPU vis setTimeout(,0) is not a problem if it is what the application intended. I don't quite agree - even though this may have been the intention, the application developer will not be aware of all the consequences without testing in Safari/Chrome. The site will work perfectly in IE and Firefox, but in WebKit-based browsers, it will eat battery, make the computer too hot to hold on one's knees, and change the pitch of noise coming from it. These are quite practical issues. It may also work faster - but chances are that this delay is not important for user experience, given that the code was deployed and works adequately in other browsers. Otherwise, I certainly agree that having a high resolution timer support is a good idea. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
I think we agree on this point - its a matter of what did the website author intend. I believe there are legitimate cases to ask for setTimeout(1). With a pure clamp based approach, this feature is not available today. On the other hand, if the website author accidentally uses setTimeout(1), then they'll see varying behavior on different browsers. I'm sure most website authors are not aware that setTimeout(1) could mean 10 or 15ms. The distinction here is quite subtle, and of course there is no standard which indicates that it would be anything other than the timeout requested. 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. Intentionally spinning the CPU vis setTimeout(,0) is not a problem if it is what the application intended. I don't quite agree - even though this may have been the intention, the application developer will not be aware of all the consequences without testing in Safari/Chrome. The site will work perfectly in IE and Firefox, but in WebKit-based browsers, it will eat battery, make the computer too hot to hold on one's knees, and change the pitch of noise coming from it. These are quite practical issues. It may also work faster - but chances are that this delay is not important for user experience, given that the code was deployed and works adequately in other browsers. Otherwise, I certainly agree that having a high resolution timer support is a good idea. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Agreeing with Alexey's points here and adding one more... On Sep 30, 2008, at 9:32 AM, Alexey Proskuryakov wrote: Sep 30, 2008, в 8:13 PM, Mike Belshe написал(а): Thanks - I did see that bug. Intentionally spinning the CPU vis setTimeout(,0) is not a problem if it is what the application intended. I don't quite agree - even though this may have been the intention, the application developer will not be aware of all the consequences without testing in Safari/Chrome. The site will work perfectly in IE and Firefox, but in WebKit-based browsers, it will eat battery, make the computer too hot to hold on one's knees, and change the pitch of noise coming from it. These are quite practical issues. It may also work faster - but chances are that this delay is not important for user experience, given that the code was deployed and works adequately in other browsers. And, as Maciej pointed out with the JQuery case, it may also cause the application to work SLOWER. It seems likely that JQuery uses setTimeout(0) not because they expect their code to actually run cyclically with zero delay, but because they are aware that 0 in this context means minimum, well aware that this means 10ms or 15.6ms for a vast majority of users. Introducing this incompatibility would make WebKit-based browsers broken compared to all other major browsers. And it would not be a simple 1 character fix as you suggest, as thousands of websites have thousands of copies of dozens of versions of JQuery and there is no master rollout that could fix them all at once. And pretend you do fix them after a lengthy battle - what happens when you identify the next ill-behaving component? I think that dancing around setTimeout() has no specified minimum timeout as an argument for adding this incompatibility is kind of crazy. True, there's no spec or standard that decides between 10ms, 15.6ms, or some other value. But the web has already decided a de- facto standard which seems to be more important than a spec in this case. I, too, fully support a high res timer API as a separate, cross- platform addition. ~Brady Otherwise, I certainly agree that having a high resolution timer support is a good idea. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а): As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur non-trivial processor usage. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
2008/9/30 Mike Belshe [EMAIL PROTECTED] As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Followup to my earlier post, based on this. I realize that one reason why we (Chromium folks) have not been as concerned about CPU usage is that in a multi-process world, excessive CPU is an annoyance, but doesn't completely break the app. This wouldn't necessarily be the case in a single-process consumer of WebKit, e.g. Safari, where a page in a tight JS loop could make the whole browser less responsive. This seems like a legitimate reason to be concerned about excessive CPU usage. Mike's suggestion that we can find a minimum timeout value (e.g. 3 ms) where the CPU doesn't get pegged seems reasonable if this is the main issue. And a few more thoughts on app compat. Using more CPU is not an app compat concern. The CG GIF decoder that Safari uses burns 10x the CPU that Gecko's does, such that on various animated GIFs I can hit 60% of one of my (very fast!) cores just animating a single image in Safari. But no one has ever presented this as a web app compat issue, even though tons of web pages use animated GIFs; it's just a bug/optimization opportunity. Chromium uses extra CPU due to having plugins out of process. Gecko uses more CPU to relayout than WebKit. None of these are compatibility issues. The comments on bug 6998 imply to me that the 10ms cap was put in because Safari was eating more CPU than other browsers, not because there were animations running at the wrong speed or stylesheet loads not being sensed soon enough. I think if we can agree that not pegging the CPU, rather than precisely matching other browsers (which is impossible due to their 60% variance from each other), is the chief objection to uncapped timers, it will be easier to move forward. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Sep 30, 2008, at 9:37 AM, Mike Belshe wrote: 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 through the webkit bugs database as much as I could, and could not locate them. When these problems occur they are usually bugs in the Web site that do (eventually) get discovered and fixed. In the past our evangelism people have had to contact sites to fix these kinds of issues. This is why simply surfing to sites doesn't really give an accurate picture of how this works. In our experience, sites redesign or add new features (this was the case with Amazon), and the new feature will have a setTimeout use that wasn't tested in Safari. With no clamp, we'd end up eating 100% CPU until the site fixed the problem (which could take months sometimes). 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 in your eyes? Yes, I was considering this also. To me the primary issue with removing the setTimeout clamp is CPU hogging and not animation speed. I do think lowering the clamp is reasonable. I still think we should have an unclamped high res timer API though, regardless of what we decide with setTimeout. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
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 in your eyes? Yes, I was considering this also. To me the primary issue with removing the setTimeout clamp is CPU hogging and not animation speed. I do think lowering the clamp is reasonable. I still think we should have an unclamped high res timer API though, regardless of what we decide with setTimeout. OK - I created a second version of my timer test to help with testing of this. (these are only interesting tests to run on browsers which unclamp the timers) Here is the test I created before: http://www.belshe.com/test/timers.html The problem is that this will use lots of CPU just doing paints (it paints with every iteration). Most background spinners don't have this property. http://www.belshe.com/test/timers2.htmlhttp://www.belshe.com/test/timers.html This case only updates the UI every 1000 iterations. With this test, the CPU load is almost zero even with a 2ms timer. Using a slightly more conservative minimum should account for slower processors and also allow for a little more work to be done in the setInterval loop. Regarding the API - yes. I'd like the units of time for the new API to be at most measured in microseconds; 100-nanos might be more forward-thinking. Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Hi Peter, On Sep 30, 2008, at 8:42 PM, Peter Kasting wrote: 2008/9/30 Mike Belshe [EMAIL PROTECTED] As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Followup to my earlier post, based on this. I realize that one reason why we (Chromium folks) have not been as concerned about CPU usage is that in a multi-process world, excessive CPU is an annoyance, but doesn't completely break the app. This wouldn't necessarily be the case in a single-process consumer of WebKit, e.g. Safari, where a page in a tight JS loop could make the whole browser less responsive. This seems like a legitimate reason to be concerned about excessive CPU usage. Mike's suggestion that we can find a minimum timeout value (e.g. 3 ms) where the CPU doesn't get pegged seems reasonable if this is the main issue. And a few more thoughts on app compat. Using more CPU is not an app compat concern. The CG GIF decoder that Safari uses burns 10x the CPU that Gecko's does, such that on various animated GIFs I can hit 60% of one of my (very fast!) cores just animating a single image in Safari. But no one has ever presented this as a web app compat issue, even though tons of web pages use animated GIFs; it's just a bug/optimization opportunity. Chromium uses extra CPU due to having plugins out of process. Gecko uses more CPU to relayout than WebKit. None of these are compatibility issues. The comments on bug 6998 imply to me that the 10ms cap was put in because Safari was eating more CPU than other browsers, not because there were animations running at the wrong speed or stylesheet loads not being sensed soon enough. I think if we can agree that not pegging the CPU, rather than precisely matching other browsers (which is impossible due to their 60% variance from each other), is the chief objection to uncapped timers, it will be easier to move forward. The problem is not only confined to single processor systems. As others have mentioned the bigger problem is the waste of resources. The length of the timeout is not the full piece of the puzzle. There's also problems with what the application does at the end of each timeout. This often needless processor use ends up draining batteries, increasing heat and wasting energy (even with a multiprocessor system). 2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED] Sep 30, 2008, в 9:12 PM, Mike Belshe написал(а): As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Maybe, partially. As mentioned in bug 6998, even 10 ms timers incur non-trivial processor usage. Your comment in that bug was that it was 3.7% of CPU on your machine. 3.7% for as fast as possible doesn't seem like a huge burden. That suggests authors could write tight loops at 3ms delays and still only burn 10% of the CPU. I think that's a reasonable proposal. Again, the length of the timeout is not the only thing determining CPU usage. The response to the timeout also influences CPU usage. If the timeout is clamped at 3ms instead of 12ms, then it is using the processor 4X as much (assuming that it doesn't also introduce synchronization problems the author didn't anticipate). That is quite significant. Given the growing importance in mobile processing it seems rather irresponsible to promote this waste of processor resources. Take care, Rob___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Or there is option 3: 3) Restore the clamp for setTimeout and setInterval to 10ms for compatibility, and add a new setHighResTimer API that does not have any lower bound. I'd like to tweak this suggestion a bit: Let's make this new timer API object-oriented, so it can be both less slow and less crazy than setTimeout / setInterval. There are many Timer APIs in open source JavaScript libraries on which we could base a new API. Perhaps a Timer object would always be high resolution, or perhaps it would have an isHighResolution bit. Cheers, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
Fwiw, ActionScript 3 implements a Timer API we could use a basis: http://livedocs.adobe.com/flex/2/langref/flash/utils/Timer.html It basically is an OOP based timer/interval API. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoffrey Garen Sent: Tuesday, September 30, 2008 3:58 PM To: Maciej Stachowiak Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] setTimeout as browser speed throttle Or there is option 3: 3) Restore the clamp for setTimeout and setInterval to 10ms for compatibility, and add a new setHighResTimer API that does not have any lower bound. I'd like to tweak this suggestion a bit: Let's make this new timer API object-oriented, so it can be both less slow and less crazy than setTimeout / setInterval. There are many Timer APIs in open source JavaScript libraries on which we could base a new API. Perhaps a Timer object would always be high resolution, or perhaps it would have an isHighResolution bit. Cheers, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Tue, Sep 30, 2008 at 12:17 PM, Rob Burns [EMAIL PROTECTED] wrote: The problem is not only confined to single processor systems. As others have mentioned the bigger problem is the waste of resources. The length of the timeout is not the full piece of the puzzle. There's also problems with what the application does at the end of each timeout. This often needless processor use ends up draining batteries, increasing heat and wasting energy (even with a multiprocessor system). I never said there was no problem at all. I said the problem was not a web compat issue, and therefore not one on which all browsers were required to agree. It's a prolem, but a narrowly-scoped one, such that tradeoffs are possible. Your comment in that bug was that it was 3.7% of CPU on your machine. 3.7% for as fast as possible doesn't seem like a huge burden. That suggests authors could write tight loops at 3ms delays and still only burn 10% of the CPU. I think that's a reasonable proposal. Again, the length of the timeout is not the only thing determining CPU usage. The response to the timeout also influences CPU usage. If the timeout is clamped at 3ms instead of 12ms, then it is using the processor 4X as much (assuming that it doesn't also introduce synchronization problems the author didn't anticipate). That is quite significant. Given the growing importance in mobile processing it seems rather irresponsible to promote this waste of processor resources. But again, 4x as much as what? 3 ms as opposed to 10 ms is ~3x as much CPU usage as something that used 3.7% of CPU on a machine two years ago. This is roughly what Moore's Law has already given you back. And I hardly think it promotes a waste of processor resources to give apps the CPU they're explicitly asking for since, as I've said, nearly every case we've run into is a case where authors _want_ as much responsiveness as possible. FWIW, I'm in favor of an additional API alongside this one if it enables fully-uncapped timers and higher resolution than 1 ms -- but I don't think that changes the argument for also lowering the cap on setTimeout(). If taking ggaren's object-oriented suggestions into account makes life easier on JS library authors then I'm for that too. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Tue, Sep 30, 2008 at 1:35 PM, Brady Eidson [EMAIL PROTECTED] wrote: If we add a new well specified API that all browser vendors agree on, everybody wins. No; everybody who's willing and able to change wins. Everyone else wins or loses depending on whether the new behavior is better or worse for them. My argument is that this makes life better for nearly all pages affected. The entire reason to change setTimeout() is precisely _because_ not everyone will change their web pages. (Furthermore, I claim the number of people who will realize they could get something better, and change their code to get it, is lower than the number of people who will see that something is wrong and fix it.) negates the need to introduce new incompatibilities into the already published web by changing setTimeout(). This still implies there is a meaningful compatibility hit to making this change. I have not yet seen any reason to agree that is the case (in the sense of CPU usage is not a web compatibility issue). There is _already_ no compatibility here. Browsers do completely different things, of an equivalent magnitude (6 ms) to the suggested change of 10 ms - 3 or 4 ms. Firefox is even different based on whether Flash happens to be running! How can there be compatibility problems introduced by this proposal that don't already exist? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Tue, Sep 30, 2008 at 2:50 PM, David Hyatt [EMAIL PROTECTED] wrote: Note that these problems in Safari came from having no clamp at all. Even Chrome has a 1ms clamp. Right. We weren't proposing making setTimeout() unclamped; just lowering the clamp. (And I'm sorry for using the word unclamp in my first email and thus totally muddying the waters here; mea culpa.) While we currently use a 1 ms clamp, 3 or 4 ms also seem like reasonable possibilities. When we made the change in our tree, we looked very carefully for sites it would affect. We continued to look for the several months we tested after that, and during our public release. So far we just have not seen a major web compatibility issue. There have been a couple of cases we've seen that use more CPU than we'd like, which would be addressed by using a 3 ms clamp instead of 1 ms. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
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 forward. If you recall - there used to be a TURBO button on PCs as they made the switch from 8MHz to 12MHz to address this issue. Turbo buttons don't exist anymore. Anyway, this is a personal preference; I have little sympathy on the game front - but more sympathy on the accidental CPU front. Mike On Tue, Sep 30, 2008 at 2:47 PM, Oliver Hunt [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 1:41 PM, Peter Kasting wrote: On Tue, Sep 30, 2008 at 1:35 PM, Brady Eidson [EMAIL PROTECTED] wrote: If we add a new well specified API that all browser vendors agree on, everybody wins. No; everybody who's willing and able to change wins. Everyone else wins or loses depending on whether the new behavior is better or worse for them. My argument is that this makes life better for nearly all pages affected. The entire reason to change setTimeout() is precisely _because_ not everyone will change their web pages. Okay, lets try this, there a 3 possibilities win, no change, and lose, here are the groups: New API No timer clamp Benefits from higher precision timer No change Win Hurt by high precision timer No change lose Hurt by timer and willing to update No change lose (extra work) Benefits from timer and willing to update Win Win So while two groups win with the chrome model, two groups actually lose either due to site breakage, or having to do extra work to avoid breakage. Whereas with a new API while only one group actually wins no others are effected. (Furthermore, I claim the number of people who will realize they could get something better, and change their code to get it, is lower than the number of people who will see that something is wrong and fix it.) I would disagree -- people who need high precision timers, and realise that they're there *will* use them. Sites that are broken by a buggy setTimeout implementation won't. Hell I have seen sites with actual bugs (eg. bugs in the site, not in the browser) where i have provided an actual patch to correct the bug and they still don't fix it. All a broken setTimeout implementation will do is result a site making the easy change of saying don't use this browser because it's broken. They do that even when the bug is in their site, so an actual browser bug is even easier to ignore. negates the need to introduce new incompatibilities into the already published web by changing setTimeout(). This still implies there is a meaningful compatibility hit to making this change. I have not yet seen any reason to agree that is the case (in the sense of CPU usage is not a web compatibility issue). There is _already_ no compatibility here. Browsers do completely different things, of an equivalent magnitude (6 ms) to the suggested change of 10 ms - 3 or 4 ms. Firefox is even different based on whether Flash happens to be running! How can there be compatibility problems introduced by this proposal that don't already exist? Um, i would guess on Vista all browsers have a 10ms timeout, on XP the only reason the 15ms timeout clamp exists is because of XP's low default timer resolution. On Mac and (I assume all unixes/bsds/linux) the timeout clamp is likely to be 10ms. But even the 15ms timeout is only 1.5x longer that 10ms, where as 1ms represents an order of magnitude difference. If we were to look at a game that for instance assumed a 15ms clamp on setTimeout, and used that as the game clock tick (which happens) then a game that used to get maybe 50 updates a second will get 66 updates if you have 10ms timer. With a 1ms resolution timer though the game will get *160fps*, eg. 3 times faster than was intended. --Oliver * A very quick google brought up: http://www.c-point.com/javascript_tutorial/games_tutorial/how_to_create_games_using_javascript.htmwhich uses a 0ms timeout to trigger torpedo motion * From a comment on john resig's blog I saw a javascript game yesterday that had to LIMIT the framerate because google chrome made it unplayable. -- so there are sites that have already had to do work to not break with this model -- how many else are out there? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Sep 30, 2008, at 10:42 AM, Peter Kasting wrote: 2008/9/30 Mike Belshe [EMAIL PROTECTED] As for keeping the fan off - if we could keep the CPU idle a 3ms minimum timeout loop does that resolve your concern? Followup to my earlier post, based on this. I realize that one reason why we (Chromium folks) have not been as concerned about CPU usage is that in a multi-process world, excessive CPU is an annoyance, but doesn't completely break the app. This wouldn't necessarily be the case in a single-process consumer of WebKit, e.g. Safari, where a page in a tight JS loop could make the whole browser less responsive. This seems like a legitimate reason to be concerned about excessive CPU usage. Mike's suggestion that we can find a minimum timeout value (e.g. 3 ms) where the CPU doesn't get pegged seems reasonable if this is the main issue. That seems like incorrect reasoning to me. unclamped setTimeout(0) does not break processing of user events in a single-process browser (I tested). But it will equally drain your laptop battery and produce a great deal of heat and noise with single-process and multiprocess architectures. And a few more thoughts on app compat. Using more CPU is not an app compat concern. The CG GIF decoder that Safari uses burns 10x the CPU that Gecko's does, such that on various animated GIFs I can hit 60% of one of my (very fast!) cores just animating a single image in Safari. But no one has ever presented this as a web app compat issue, even though tons of web pages use animated GIFs; it's just a bug/optimization opportunity. Chromium uses extra CPU due to having plugins out of process. Gecko uses more CPU to relayout than WebKit. None of these are compatibility issues. At the extreme, performance issues can be compatibility issues. The comments on bug 6998 imply to me that the 10ms cap was put in because Safari was eating more CPU than other browsers, not because there were animations running at the wrong speed or stylesheet loads not being sensed soon enough. I think if we can agree that not pegging the CPU, rather than precisely matching other browsers (which is impossible due to their 60% variance from each other), is the chief objection to uncapped timers, it will be easier to move forward. I think if we agree that there should be some lower bound on the normal timer API, to protect against sites only tested in normal browsers, then we would want to also introduce a high resolution timer API with no limit for aware apps to use. In which case it seems prudent not to change the timeout from the range of what other browsers do. That way there is no risk to legacy content, but new content can get the full benefit (rather than being throttled to 3ms or 1ms). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Sep 30, 2008, at 5:13 PM, Peter Kasting wrote: On Tue, Sep 30, 2008 at 3:53 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Can you cite some of the existing sites that would benefit? That would help others confirm the benefit and also estimate likelihood of said sites adopting a new better API for greater benefit. Sure. http://ajaxian.com/archives/running-cpu-intensive-javascript-computations-in-a-web-browser describes how to make apps doing long-running calculations responsive by breaking them into small chunks and using setTimeout(..., 0). This is precisely the type of pattern we hope to speed up. On the sample page at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process.html , Chromium runs the test in about 1 sec, compared to ~15.6 sec in Safari 3.1. Even the optimized version at http://www.julienlecomte.net/blogfiles/javascript/long-running-js-process-optimized.html is still faster. An obvious example is John Resig's timer perf bench at http://ejohn.org/apps/timers/ , which I'm sure you're familiar with. This loads up about 15x faster since it uses setTimeout(..., 0). One can argue about the relative worth of this benchmark, of course, but then I seem to remember from our last lunch that the WebKit team generally had the philosophy of speed up the benchmark regardless, and complain about the validity of it in parallel if necessary :) These two are some of the most obvious cases, where loading the page takes dramatically less time, but there are more subtle wins. For example, Chromium should save about 9 ms on http://www.benya.com/code/jsbenchmarks/table-rendering-benchmarks.html due to the uncapping. A sample page which is theoretically, but seemingly not practically, helped by this is http://hassing.org/projects/asteroids/ . At least on my machine, the CPU load is low enough that the difference between Safari's 100 FPS cap and Chromium's 1000 FPS cap is unnoticeable. I suppose that on a slow/heavily loaded machine things might be different; not sure. Similarly, http://cometdaily.com/2008/08/11/robust-network-code-with-windowsettimeout/ describes a pattern that will save a bit of time on some callbacks, but I don't actually have a testcase where that sample code is used. These few examples are what I had off the top of my head. If you'd like, we can do a more exhaustive search for affected pages and get back to you with the results. (The guy who has that data isn't around ATM.) It seems to these are demo pages, tutorials, or descriptions of techniques. Clearly tutorials and demos can adapt to a new API, and improving their current form is not much of a benefit. How about real existing sites that benefit? That is what you cited that as the justification for changing the existing setTimeout / setInterval APIs, rather than relying solely on new API. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Sep 30, 2008, at 5:15 PM, Mike Belshe wrote: 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(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 forward. If you recall - there used to be a TURBO button on PCs as they made the switch from 8MHz to 12MHz to address this issue. Turbo buttons don't exist anymore. Anyway, this is a personal preference; I have little sympathy on the game front - but more sympathy on the accidental CPU front. Our attitude towards Web compatibility generally is that if a Web site works reasonably in other browsers but does not work in Safari, then it is presumptively our bug. That is what users will assume, and lectures about how foolish the site developer was tend to have little effect. Thus, sympathy or lack thereof for particular use cases does not enter into the picture. We should not be making these kinds of decisions based on our own personal opinions of the coding quality of the site. If you follow this to the logical conclusion, then WebKit should use a 15.6ms timer. :-) My point is that applications which are hard coded to work with a particular minimum timer value are broken already today across browsers (some are 10, some are 15, and these are significantly different). Such applications were probably built and tested on a limited set of browsers, but it does not matter why they are this way. Given that these apps already behave differently in existing browsers, I'm much less concerned about this issue than the CPU issue. Degree of difference matters too, not just whether there is one. For example, a browser using a different antialiasing algorithm for text would be much more acceptable than a browser that renders black text as bright yellow, event though both in theory could make a page look different than intended. In practice, a timer value of 10ms instead of 15.6ms does not appear to be a problem, we have historic evidence that 0ms minimum is a problem, scattered evidence that 1ms may be a problem, and no clear information on values in between such as 3ms, 5ms or 7ms. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Sep 30, 2008, at 6:37 PM, Peter Kasting wrote: On Tue, Sep 30, 2008 at 5:31 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: It seems to these are demo pages, tutorials, or descriptions of techniques. Clearly tutorials and demos can adapt to a new API, and improving their current form is not much of a benefit. How about real existing sites that benefit? You're right; my list sucked. I thought we had a list of sites that were helped that led us to do this and posted assuming that without checking. I shouldn't have asserted something I hadn't verified, and I should have said so immediately afterwards. I'm sorry. I think our original motivation was that we wrote some code very like the benchmarks Mike posted to start this thread, and found things were unexpectedly slow. We hadn't realized there'd be a minimum value on setTimeout() since there wasn't a spec that said that and it wasn't intuitive that there should be one; if we had made this mistake, surely others would have, so we wondered if we could improve things for people in general. When we considered lowering it we worried quite a bit about web compat, but were unable to find any problems in several months of daily usage, or in our explicit testing of all the related sites we could find from old WebKit bugs about this. And since launch I believe we still haven't seen problems of sites intentionally using setTimeout(0) and having difficulties; the one problem I'm aware of involves double-inclusion of a script that leads to an orphaned timer spinning in the background. But I'm not sure, maybe there have been other cases we know of. I still think this is the right thing to do, though I don't seem to have any convincing evidence for it. Darin's comments on bug 6998, or John Resig's comments on his blog post about Chromium's behavior here, or Hyatt's comments earlier in this thread, echo parts of my feelings, which are: authors should be able to get called back ASAP when they do this, where ASAP is subject to the limits of the platform, not burning 100% of the CPU, etc. I assume there are sites out there that legitimately benefit from our changes, but I think we made our decision before having such a list. So I am sorry for being so forceful with this opinion previously and that I don't have good data to support it. We (the Chromium folks) want to help make the web better and it seems like we've been getting off on the wrong foot a lot lately in broader WebKit discussions, but I hope you will still consider our opinions seriously. Sometimes we have acted on instinct, theory, and limited data, but I'm not sure that that means all of those decisions have been wrong. That's ok, we are used to some forceful assertion of opinions in the WebKit community. :-) As long as we can ultimately come to a good resolution, it's ok if the discussion goes off on some tangents. Indeed, I think a lot of good ideas and information have come up in this thread, and I am glad that we had this discussion. This list should be a safe space for freewheeling (but respectful) technical discussions. But on the other hand, In the history of WebKit development we have a strong tradition of using data, measurements and testing to evaluate changes, particularly in the areas of performance, memory use and Web compatibility. Our experience with performance especially is that improvements based on guesswork or instinct rather than measurement tend to be ineffective. One advantage of data and measurements is that they tend to be easier for a heterogenous organization to agree on than theories or instincts. I agree with you that web content authors should have a way to get called back ASAP. It seems like we have three different proposals identified that most have agreed are worth pursuing: 1) Design an improved timer API that is object-oriented and supports high resolution, with no artificial lower limit. Propose for HTML5, implement in WebKit, encourage other browser vendors to implement it. Am I right that there's rough consensus we should do this? If so, I can circulate a rough cut proposal on this list, and then move discussion of this idea to the WHATWG. 2) Consider making WebKit's default minimum timer limit lower - something like 3ms-5ms. I don't know what we would do to verify that this is safe enough or who would do the work. Maybe Hyatt? 3) Determine whether other browser vendors would be willing to change the minimum timeout for setTimeout and setInterval (which would not eliminate the risk with legacy content but would reduce its severity over time). If others agree this is worth pursuing, I can at least ask on the HTML WG mailing list. Thoughts? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
On Tue, Sep 30, 2008 at 7:14 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: I agree with you that web content authors should have a way to get called back ASAP. It seems like we have three different proposals identified that most have agreed are worth pursuing: 1) Design an improved timer API that is object-oriented and supports high resolution, with no artificial lower limit. Propose for HTML5, implement in WebKit, encourage other browser vendors to implement it. Am I right that there's rough consensus we should do this? If so, I can circulate a rough cut proposal on this list, and then move discussion of this idea to the WHATWG. 2) Consider making WebKit's default minimum timer limit lower - something like 3ms-5ms. I don't know what we would do to verify that this is safe enough or who would do the work. Maybe Hyatt? 3) Determine whether other browser vendors would be willing to change the minimum timeout for setTimeout and setInterval (which would not eliminate the risk with legacy content but would reduce its severity over time). If others agree this is worth pursuing, I can at least ask on the HTML WG mailing list. These all seem like avenues worth pursuing. I can try and get more data about the impact, both positive and negative, of setTimeout()/setInterval() changes; hopefully that will help make the discussions of (2) and (3) a bit more concrete. Now if only I could get all the browser vendors to agree on their minimum GIF frame durations :D PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setTimeout as browser speed throttle
We encountered 100% CPU spins on amazon.com, orbitz.com, mapquest.com, among others (looking through Radar histories). This was pre-clamp. Web sites make this mistake because they don't know any better, and it works fine in IE. It is a mistake these sites will continue to make, and Chrome is the only browser that will be susceptible. Being different from IE here is not a good thing. You will end up having to evangelize sites over and over to fix 100% CPU spins that occur only in your browser. Do you really want that 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 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 this was to minimize browser delays when running graphical javascript applications. This has been a concern for some, so I wanted to bring it up here and get an open discussion going. My hope is to lower or remove the clamp over time. To demonstrate the benefit, here is one test case which benefits from removing the setTimeout clamp. Chrome gets about a ~4x performance boost by reducing the setTimeout clamp. This programming pattern in javascript is very common. http://www.belshe.com/test/sort/sort.html One counter argument brought up is a claim that all other browsers use a 10ms clamp, and this might cause incompatibilities. However, it turns out that browsers already use widely varying values. I believe all major browsers (besides Chrome) have a minimum of either 10ms or 15.6ms. I don't think this is widely varying. We also really haven't seen any incompatibilities due to this change. It is true that having a lower clamp can provide an easy way for web developers to accidentally spin the CPU, and we have seen one high-profile instance of this. But of course spinning the CPU can be done in javascript all by itself :-) The kinds of problems we are concerned about are of three forms: 1) Animations that run faster than intended by the author (it's true that 10ms vs 16ms floors will give slight differences in speed, but not nearly as much so as 10ms vs no delay). 2) Burning CPU and battery on pages where the author did not expect this to happen, and had not seen it on the browsers he or she has tested with. 3) Possibly slowing things dow if a page is using a 0-delay timer to poll for completion of network activity. The popular JavaScript library jQuery does this to detect when all stylesheets have loaded. Lack of clamping could actually slow down the loading it is intended to wait for. 4) Future content that is authored in one of Safari or Chrome that depends on timing of 0-delay timers will have different behavior in the other. Thus, we get less compatibility benefit for WebKit-based browsers through cross-testing. The fact that you say you have seen one high-profile instance doesn't sound to me like there are no incompatibilities. It sounds like there are some, and you have encountered at least one of them. Points 1 and 2 are what made us add the timer minimum in the first place, as documented in WebKit's SVN history and ChangeLogs. We originally did not have one, and added it for compatibility with other browsers. Currently Chrome gets an advantage on some benchmarks by accepting this compatibility risk. This leads to misleading performance comparisons, in much the same way as firing the load event before images are loaded would. Here is a summary of the minimum timeout for existing browsers (you can test your browser with this page: http://www.belshe.com/test/timers.html ) Safari for the mac: 10ms Safari for windows:15.6ms Firefox: 10ms or 15.6ms, depending on whether or not Flash is running on the system IE : 15.6ms Chrome: 1ms (future - remove the clamp?) So here are a couple of options: 1) Remove or lower the clamp so that javascript apps can run substantially faster. 2) Keep the clamp and let them run slowly :-) Thoughts? It would be great to see Safari and Chrome use the same clamping values. Or there is option 3: 3) Restore the clamp for setTimeout and setInterval to 10ms for compatibility, and add a new setHighResTimer API that does not have any lower bound. This would let aware Web applications get the same benefit, but without any of the compatibility risk to legacy Web content. The main argument against doing things this way is that it would add API surface area. But that seems like a small price to pay for removing the
