[webkit-dev] setTimeout as browser speed throttle

[Rob Burns]

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 <robburns1 at mac.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081003/b0f51749/attachment.html