Background Music
Posted by Dave Hyatt on Tuesday, February 27th, 2007 at 5:26 pmmacenstein.com has an interesting article about a slowdown in other applications when a Safari window with a specific set of pages is loaded in the background. What a browser should do when it is the background application is actually extremely complex, and not all of the decisions are as clear-cut as they might seem.
Before I drill into the specifics of what a browser does with background Web pages, I’d like to first state that it’s dangerous to jump to any general conclusions when the sample set of pages is very small. In the example article cited above, the author visited five Web sites and clicked around within them. It’s possible that this pathological behavior is specific not just to one Web site but possibly even to one specific page on that Web site. In order to identify the problem it would be better to try the test again with each individual page.
One might expect that a background browser window would do nothing. However, that is a fairly naive assumption once you take a look at the kind of Web content that exists today. There are many ways in which a browser can still be doing required work even while in the background. Here are some examples:
(1) Animated GIFs
Animated GIFs that are clearly visible in a background window must continue to animate. Especially for animated GIF “movies”, people do switch to other windows or apps and expect to be able to watch the movie still while doing other things. In Safari 2, GIFs animate on separate timers (1 unique timer per individual URL) and so this can get reasonably CPU intensive. The fastest any individual GIF can animate is 10ms, so any single GIF is effectively throttled. However once you get many unique images animating at different rates on a page, you can potentially end up firing timers at a much faster rate. In WebKit nightlies we have improved animation so that there is a single timer driving all of the animations. The unified timer helps control the CPU usage, since updates can be coalesced if they occur very close together.
In both Safari 2 and WebKit nightlies, GIFs don’t animate unless they are being painted somewhere. If an animated GIF becomes invisible, then the animation will pause and no CPU will be consumed by the animation. Therefore all animated images in a background tab will not animate until the page in that tab becomes visible. If an animated GIF is scrolled offscreen even on a foreground page, it will stop animating until it becomes visible again.
Safari’s CPU usage with animated GIFs is very good. (For a while readers of MacNN thought Safari had an “animated GIF problem” because of slowness when typing in forum posts, but that bug actually had to do with the Flash ads at the top and bottom of the page.)
(2) Plugins
Plugins are another area where work can occur while a Safari window is in the background. The Mac plugin framework is really archaic (in Safari and Firefox). Many plugins do animation and work based off being pumped “null events” in which they do processing. The faster you pump these events, the faster animations will occur, and the more CPU will be used. Safari 2 actually throttles these events aggressively to background windows and background tabs.
However what we found when we did this was that users complained about the “slow plugin” problem of background windows. They wanted to be able watch videos or listen to audio through browser plugins and have another app active. In other words users *wanted* the browser to be working actively for them even while in the background. We have actually changed our behavior in the latest WebKit to only throttle backround tabs. Background windows are no longer throttled so that plugins can animate properly at normal speed. We expect that some users still won’t be happy with this change in the one case of wanting to listen to audio in a background tab, but we had to draw the line somewhere.
(3) JS Timeouts and Intervals
setTimeout and setInterval from JS are the third most common way of doing repeating animation/work. We can’t really avoid responding to timers in background tabs/windows, since Web pages rely on this work actually getting done as the foundation of AJAX Web applications. Safari 2 has a key difference from Firefox and WinIE that I suspect is the root of the additional slowdown described in the article above.
Some Web pages specify repeating timers with an extremely small timeout. In fact they often use the value 0 to mean “Fire as soon as you can.” Safari 2 does not throttle these timeouts, and so a poorly-constructed page that specifies a repeating timer under 10ms will actually hog a lot of CPU. Aggressive timers were actually a problem in Mozilla for a long time before being fixed, and they are currently a problem in Safari 2. WinIE, Firefox, and WebKit nightlies basically error-correct the badly constructed page and ignore timer values of < 10ms by changing them to be 10ms. I suspect the root cause of the issue above is just that one of the pages is hogging the CPU with an aggressive repeating timer, but I am prepared to be surprised. 
(4) Marquees
The marquee element can also animate. By default however it is clamped so that it cannot consume too much CPU (60ms ticks of a clock). An attribute called TRUESPEED can be used on a marquee, however, to tell the browser that it should honor the real animation rate (even if it’s really fast). There is a small (but unlikely) chance that a marquee occurred on one of those pages. I don’t believe Firefox supports the TRUESPEED attribute while we do for WinIE compatibility, so this does mean that certain marquees could consume more CPU in Safari than in Firefox. If so, this would be by design (and would match Internet Explorer for Windows). This attribute rarely occurs on the Web, though, so it is unlikely that it is the cause of any real-world slowdowns.
(5) XMLHTTPRequests
Finally a Web page that seems “loaded” may not be because of AJAX-style asynchronous load requests. Because these requests don’t result in any progress bar or load animation, this work can be very subtle (it can basically be going on without the user knowing about it). However, usually the data fetched by such requests loads quickly and on another thread, so it’s unlikely to significantly interfere with the running of other applications.
(6) The Back/Forward Cache
When everything works as planned, pages that go into the back/forward cache suspend all of their running animations. This includes plugins, marquees, JS timers and animated images. It’s possible that some page got into the B/F cache without being properly paused.
A few other final points to make are:
(1) Browsers rarely get served the same content, even on very popular sites. Without spoofing it’s hard to know if Safari is being served some buggy content from one of the pages in question.
(2) A small sample set isn’t enough to draw general conclusions. Try a bunch of other different Web sites and see if a slowdown still occurs. If so, then maybe there is a systemic problem. Until then, though, all we know is that something is hogging CPU in one of five Web pages.
(3) Reduce reduce reduce! Reduce the problem if possible. Cut it down to one page. Don’t go back/forward (just go right to the pages instead of clicking through to them).
Provide us with precise steps to reproduce and we can verify what the problem is and fix it very quickly. In fact, it may have already been fixed!
February 27th, 2007 at 5:49 pm
Does this mean I should set setTimeout to 10ms even when I want to do threads in javascript?
February 27th, 2007 at 6:08 pm
It’s no big deal unless you’re doing a repeating animation. If so, then if you want to avoid being too aggressive in Safari 2 you should use a value of 10ms or higher. Firefox, WinIE and WebKit nightlies are all just taking the number you pass in and raising it to 10ms if it’s too small anyway.
February 27th, 2007 at 6:09 pm
Win32’s SetTimer function actually isn’t very high resolution, so it could be that this 10ms value has more to do with that lack of resolution than with any deliberate policy on WinIE’s part.
February 27th, 2007 at 6:12 pm
What needs fixing here is the Macromedia Flash plugin. I tell without looking if a page I’m viewing has any Flash on it because the fans in my G5 tower start roaring.
February 27th, 2007 at 6:22 pm
I don’t know how long the music part of this has been a reality, but I’ve been able to have safari in the background and listen music on PureVolume.com’s flash player for a long time, then again I’ve been using NightShift for awhile now.
But one request which I still want is the ability to load up a video on YouTube and be able to go to another tab and have the video continue playing (yeah I know I shouldn’t need that since I should be watching the video, however I have ADD and want to be able to do switch between the video and other tabs without hearing the audio drop from my video, it’s very distracting).
But why there? Firefox seems to get along just fine playing my YouTube video in another tab. Why would you limit my browsing like that to decrease a few CPU cycles? If I wanted something that limited my browsing to save CPU cycles I would use Lynx. Please, at least give the user the choice. Hell, hide the option if you want so only the power users can do it, I just want the option.
February 27th, 2007 at 6:41 pm
I don’t care so much about what Safari does in the background (I do find it a little annoying seeing Flash videos slow down when the WebKit app loses focus, but watching Flash videos is an exercise in annoyance anyway). What *does* bug me is Safari’s capricious use of memory. Safari is *consistently* the top user of memory on my original BlackBook (with 2 gigs of RAM), both “real” and “virtual”. It’s currently sitting at over 300 megs after being restarted about 24 hours ago and being mostly idle in that time. The *virtual* memory’s at 721 megs (all according to Activity Monitor, so we all have a common point of reference). It’s not unusual to see Safari sitting on 400+ MB of RAM and a gig of virtual memory. These numbers only go up. I can’t be the only person observing 25 to 50 percent of the available memory on my system being used up by Safari, can I? I continue to eschew Firefox and Camino for Safari because I *like* it, but having to kill it once a week because it’s gone from swap to thrash is maddening.
February 27th, 2007 at 6:53 pm
Please ignore Mr. Cready’s request above. Seriously, Flash is a horrible CPU hog and having it running at full speed in background tabs is a terrible idea.
February 27th, 2007 at 7:14 pm
[...] ver 1.6 GB REAL. Yeah. Ouch. Here’s to hoping Safari improves dramatically in Leopard, but something tells me not to get my hopes up.
[...]
February 27th, 2007 at 7:21 pm
ahruman:
Maybe you didn’t read my whole comment, but I’ll quote myself so you don’t have to waste your time reading th whole thing.
James W Cready:
February 27th, 2007 at 11:23 pm
The issue with flash is very real and is a very big problem. I don’t know if the fault lies with Safari or Adobe, but any time I hit a flash based site, within 15 minutes the processor utilization will spike to 100%+ and I’ll have to close the page before my MacBook burns a hole in my lap. This is a huge annoyance. http://www.nikeplus.com is one I use a lot. It happens on any site that uses Flash, though: YouTube, random ads on different sites, etc. I would love to see this fixed because I am not a fan of Firefox, but I’m about to be forced to switch.
Oh yeah… I’ve downloaded the latest Adobe flash plugin. It’s possible the problem surfaced around the time I installed it, but I’m not really sure.
February 28th, 2007 at 1:38 am
[...] Zitat Programmierung, Nebenschauplätze, Apple February 28th, 2007 Zitat von webkit.org: One might expect that a background browser window would do nothing. However, that is a fairly [...]
February 28th, 2007 at 4:53 am
Joe, I’m not sure of the relevance of your threat to switch from Safari to Firefox. Your example is http://www.nikeplus.com. If I start fresh copies of Safari, a nightly build of WebKit and Firefox (all using Flash 9.0r28), and then load http://www.nikeplus.com. After waiting for a minute for each of them to load the remote resources and proceed through to the main screen, I checked their CPU usage via the command-line ‘top -F -R’. Safari running with the system version of WebKit was hovering around 10% CPU usage on my MacBook Pro. The nightly build of WebKit was sitting at around 20%, as was Firefox. The difference of 10% CPU usage between released Safari and WebKit nightlies is almost certainly due to the “slow plugins in background windows” issue that Dave mentioned in the blog post.
In conclusion Joe, switching to Firefox as you will be “forced” to do will likely leave you worse off.
If you’re not happy with the performance of the Flash player plugin I would highly recommend you visit Adobe’s website and file a bug report. Point them at specific pages that use excessive resources and ask that they work to tune their plugin to work more efficiently. There is only so much that the browser itself can do to influence the resources that plugins can use.
February 28th, 2007 at 4:56 am
I should note that the CPU usage figures I mentioned are when the application is in the background — Terminal.app was the foreground application as that was displaying the CPU usage. When I resized the browser windows so that I could read the CPU usage with the browser in the front, all three browsers stayed relatively constant at around 20% CPU.
February 28th, 2007 at 8:20 am
Thanks, Dave. That was a very good writeup on the CPU side of the macensten article.
Although I’m a bit sceptical about the memory usage measurement methodology of macenstein it would be great to hear your take on the memory usage of Safari. I have to restart Safari once every few days because it has hogged lots (several hudreds of megabytes) of memory that it won’t release without a restart even when I close all windows.
This does not feel right, should this happen? If I want to dig deeper and make bug reports how should the memory usage be measured and what is the way Safari memory management is designed to work?
February 28th, 2007 at 8:54 am
“The Mac plugin framework is really archaic (in Safari and Firefox).” So I understand there is no need to blame Adobe for the performance problems with the Flash plugin. I thought a new type of web plugin, different from Netscape plugins, had been introduced with Mac OS X and/or Safari. Any project to fix this?
February 28th, 2007 at 9:35 am
Who cares about CPU problem when there is the real problem everybody except Apple knows about? Memory, memory, memory (or developers, developers, developers?)!! This is the problem every user who is not rebooting his/her machine every several hours has: Safari quickly grabs all available memory during your web browsing, no matter that you closed tabs you didn’t need any more or even closed all Safari windows! Have you have closed them all and waited when Safari would finally leave the memory? It won’t! You have to turn Safari off and on again to clean up your memory for another apps :(. I prefer Safari over any other browsers for OS X but this really sucks and I had this problem last two years from the 1st day I switched to Mac..and I have 1.25GB RAM. Am I doing something wrong? Developers can’t see this problem? They would have to be blind or totally ignorant!
February 28th, 2007 at 10:31 am
“They would have to be blind or totally ignorant!”
I think folks may misunderstand how memory is used on Mac OS X. The basic premise is that empty memory is wasted memory. So far I see complaints about this max value and that max value which isn’t likely relevant given that memory is attempting to be used to its fullest as a cache (often backed by files on disk allowing quick recycling of pages used for caching). The issue to look for is active / continuous paging to disk. If you see this then you maybe more justified in stating a problem exists.
February 28th, 2007 at 11:01 am
Well..let my memory be used but not by Safari that has no any window opened. I wouldn’t even watch Activity monitor if there wasn’t something wrong…and ooops - it is always when Safari gradualy used all available free memory! I don’t care if it is Safari’s problem or OS X that can’t tell Safari to leave the memory so other apps that actually need it could use it. I just see what I see and it has something in common with how Safari is using memory. What is behind it I have no clue but I am definitely surprised that developers don’t care simply because that is how we should efectively use the memory.
February 28th, 2007 at 11:21 am
I’ll echo the Safari memory leak issue. I’ve actually left a machine running several other things (no Safari or Firefox, which has also leaked) for weeks - and seen (in my menubar memory indicator) almost no increase in mem use over time. To the contrary, using Safari gradually consumes all free memory. I’d sure like that to stop.
Parallels has the same problem - memory management is not easy. I assume that with Xray, you’ll have better tools for tracing this stuff - and the Leopard versions will leak less?
In spite of the leaks, I use Safari habitually. It’s just a better browser.
February 28th, 2007 at 11:55 am
I find I have to restart Safari at least once a day to clear the virtual memory it uses. Once it passes the 1GB mark, it gets really sluggish at doing simple things like opening a new tab or window. Spinning beach ball of death. Performance or not, I still choose to use Safari as my primary browser because it really is the best all-around browser.
February 28th, 2007 at 11:56 am
Hello
browsing teh web with Safari is really every day a pleasure, I’ve often surfed for weeks without restarting Safari.
I wondered if there could also exist a recent problem with how https, or certificates were handled and verified. I too noticed recent slowdowns when surfing, with my old pismo using its (replaced : modern Samsung) disk intensively (but not the G3 processor) and being unresponsive, and this phenomenon could be a cause why some users might have noticed a slowdown with Safari. It seemed to me that the cause was every time the connection to “https” pages.
February 28th, 2007 at 1:36 pm
[...] JavaScript timeouts precisely; Firefox and Safari 3 don’t allow timeouts under 10ms. read more | digg story Posted by rickvandelaar Filed in Uncategorized [...]
February 28th, 2007 at 2:28 pm
On the Flash CPU usage issue: This is probably the main reason I use FireFox more than Safari… I have the Flashblock extension installed, so flash apps don’t run unless I manually start them.
With my old PowerBook 1.67GHz it was terrible, the fans would crank up to high speed, even with relatively simple flash apps running. Now, with my Core2Duo MacBook Pro, I don’t notice it as much — but I still use Firefox+flashblock to avoid the overhead (and all the annoying flash based advertisements).
February 28th, 2007 at 2:34 pm
[...] dy been Fixed in Nightlies Filed under: Uncategorized — recar @ 9:13 pm Safari Slowdowns had Already been Fixed in Nightlies Safari and Webkit Architect David Hyatt responds to macenstein& [...]
February 28th, 2007 at 2:43 pm
Shawn,
While yes there’s a certain extent to which empty memory is wasted memory there are limits to where this is true. For example, when Safari’s memory usage balloons to using 1.3 GB of actual RAM, even after all the windows have been closed, then there’s a problem. I documented this experience here:
http://cutterpillow.com/content/view/41/1/
I should note that the reason I noticed Safari was using so much RAM was because other applications that I was using were slowing down and there was a lot of paging going on. There is definitely a memory problem with Safari. There’s only a certain extent to how much caching is useful. When the user closes windows, resources should be freed. There’s no reason for Safari to continuously increase its RAM usage until it bogs down every app on the system.
I really hope that the memory issue is addressed in future versions of WebKit/Safari. For me this is its biggest weakness.
February 28th, 2007 at 2:48 pm
I’m still waiting for the moment when the developers at apple take their heads out of sand and finally admit that their product has major bugs such as handling xml requests, DOM issues, memory leaks etc … until then Safari will remain just another worthless piece of (whatever you wanna put there) from Apple
February 28th, 2007 at 5:24 pm
This change sounds REALLY REALLY like a major downgrade in Safari’s usability to me. I listen to youTube movies and music stuff which are coming from hidden tabs all the time. I couldn’t do that anymore which would be a real pain in the neck!
I think I asked you before: why one earth do guys not try to do it right and add more multi-threading to Safari? How about starting plugins in separate threads? Starting each tab in a separate thread? The whole business of sending fake null events would vanish. Right now, everyone is forced to do that to draw the attention to the one and only event loop …
February 28th, 2007 at 6:27 pm
i left a reply on the post on macenstein, i thought they’d seriously managed to miss the issue of RAM usage, and specifically swap space usage.
namely, the main performance killer i get from safari is its insane RAM usage, the record case i’ve observed was when it was using 2GB of swap space. my swap files were around 3.8GB according to MenuMeters, i closed down all safari windows without any change, so i hit quit, it took a few minutes before it actually quit, after which my swap files were just about 1.8GB.
then, i’m one of those people who’s always got 20-30 pages open in 2-3 different windows, and i’ve always got safari running… anyway, cause of this, i endup relaunching safari every few days to make sure it doesn’t slow down my system to much, and as for system specs, its a 1.5GHz PowerBook with 1.25GB ram atm, but i also had the same swap space issues before one of my two 1GB chips burned out on me and i had to downgrade (and damn, gotta call the shop for a replacement, i keep forgetting… lol)
anyway, i hope the ram issues have been solved with the nightlies (gonna try it out in a day or two)
February 28th, 2007 at 7:20 pm
I have no idea whether Safari has memory leaks or not. However, even when you close all windows Safari will not necessarily return to the same state as a when it was newly launched. There remains the history cache that may only get released on quit. Perhaps that’s not the best behavior and that when a window or tab is closed everything (including it’s back/forward cache) should be released.
I use Safari with an unblbievable number of open tabs and windows open for weeks (sometimes months) on end. I do admist I feel the need to restart Safari from time-to-time because of excessive slowness. But this is pretty rare and I imagine it may have something to do with an obscurely errant page I visited. Most ot the time I don’t encounter these problems.
My biggest speed issue with Safari is different than the issues raised here. I’d like to see Safari spin off a new thread when I close a tab or a window. When closing a tab or a window, Safari has some cleanup to do and sometimes I have to wait to see or close the next tab or window. If Safari spun that off into another thread it could clean that up on its own time and let me continue my browsing.
March 1st, 2007 at 7:54 am
[...] n Fog on the Shepaug River Background Music March 1st, 2007 In Background Music Dave Hyatt discusses what happens when [...]
March 1st, 2007 at 8:12 am
[...] another tool to learn Style Chages I noticed while reading a Webkit blog that the page didn’t scan as well as a Huffpo page I had been reading earlier. The difference in clarity [...]
March 1st, 2007 at 8:44 am
Hi,
I’m sorry but despite your great demonstration, Safari IS slow and have the same ‘ol bugs since v.1.x.
Its behaviors give rise to think that its computing processes are disproportionate (minutes of calculating for a simple 1+1, like). I most of the time work with Safari and it becomes frustrating. This is not just a question of multi-tab web browsing and neither by comparisons with other apps processes. I don’t want to divert the subject but I see the same type of behaviors with iCal. These two Applications seems to treat the information with similar procedures. Aren’t you aware of that?
March 1st, 2007 at 9:11 am
I’m not sure if this is related or not, but has anyone else also experienced problems where Java applets will NOT run in background tabs? For example, if you log into a Java applet based chat, then switch tabs, you’ll be disconnected. I’ve posted in the Apple support forums about it, but nobody has ever really responded. But, since we’re talking about background processes and such, I figured it might be relevant.
I don’t think it’s a good idea for Safari to start disabling background content with no way to re-enable it. Like a lot of others here, I tend to listen to music, movies, etc., (in Flash) loaded in the background of the browser while I do other things. I hope the developers will rethink this decision and either scrap the idea and work on other ways to reduce CPU/memory usage (you guys REALLY need to work on the memory usage), or will add an option to allow this behavior to be enabled/disabled by the user.
March 1st, 2007 at 9:23 am
Regarding the use null events, seems like plugin developers really shouldn’t be using them anymore in new code. Carbon event timers have been around for years and work just fine in both Safari and Firefox. It’s relatively easy to switch from null events to timers. Perhaps Apple and Mozilla should deprecate the sending of nullEvents to NPP_HandleEvent to encourage developers to make the change.
Regarding multiple threads and plugins, I’m pretty sure the NPAPI is officially not thread safe–all NPP calls are expected to come from the main thread. As a result, I suspect many plugins aren’t designed for reentrancy (ours isn’t). If the main reason for doing so is better handling of periodic events, seems like timers are a simpler solution.
March 1st, 2007 at 10:12 am
I’ve definitely noticed Safari spinning on certain webpages, and the decreased battery life that follows. It’s the primary reason I use MenuMeters with a CPU graph on all my Macs. Has there been an effort to address these potential causes you mention?
(2) Antiquated plugin API. Since you say it’s the Mac plugin API that’s antiquated, I’m guessing that it’s better on Windows and/or Linux. Why not follow their lead in designing one that doesn’t suck? I don’t know how compatibility would work - maybe a plugin that falls back to the old API automatically, shipping two plugins, or waiting to use it until its widely deployed - but none of those are options at all until the API at least exists.
(3) JS timeouts and intervals. I don’t think it’s at all unreasonable to either have a fixed 10 ms minimum timer interval (as you say Firefox does) or to start throttling back webpages if they appear to be busy looping. Why have you made a different choice from the other browsers?
(4) Marquee TRUESPEED. I don’t care about WinIE compatibility with obscure elements. If someone else does, could there be an advanced preference for this? In fact, I don’t care if it’s in the UI at all. If I have to type “defaults com.apple.Safari letDumbWebpagesSlowMySystemToACrawl false” to get my desired behavior, that’s fine.
March 1st, 2007 at 10:19 am
Er, ignore my (3) there. I didn’t notice on first read that you said WebKit nightlies throttle these timers. Maybe I need to update…
March 1st, 2007 at 12:13 pm
Speaking of the back/foward cache, the cap on the number of pages in the back/forward cache should be global across all tabs. I typically use lots of tabs, 10 +, and Safari bloats up to huge size after using it for awhile. I often size a process size of 1GB. Firefox has the same problem so it’s not unique to Safari. I’d be happy to just disable the back / forward case but I don’t think that is possible.
March 1st, 2007 at 2:03 pm
David,
Just wanted to let you know that as per your request we ran our tests again using your latest WebKit builds, and the improvement is dramatic. Hopefully you guys have actually done something different between the shipping version of Safari and this build, because otherwise we have no explanation for these results.
WebKit more or less ties Firefox in the After Effects and PhotoShop “Open” tests, and beats it handily in the PhotoShop “Save As” tests. (we posted the results under “[UPDATE 3]“, at the end of the article.)
So great work, and sorry to have caused such a fuss (although from the comments, I guess we were not alone in our experiences with the “old” Safari). Thanks for turning us on to the WebKit builds, and we look forward to Safari 3. (Feel free to leak to us when to expect that).
-The Doc
March 1st, 2007 at 2:49 pm
I need to add my vote to the ‘why is safari eating all my memory’ complaint.
I have Safari, Camino, Firefox, Opera, and some other flavors of mozilla.
I find that Safari becomes a memory pig after a while, I’ve gone to work, and then come back after 10 hours click on the safari icon and wait… and wait… and wait before it comes alive. I tend to right-click and force it to close.
I also find the same thing (non-responsiveness after significant time in the background) happens with camino.
Couldn’t a compromise be to add a menu/preferences type of option for plugin handling? Like literately bring up a list of plugins, Default to behavior as normal, with the option to ‘halt in background’,'halt in background tabs’,'halt when minimized’,'always halt’ (disable) until clicked. The point I’m trying to make here, at least be able to turn off bad plugins, or make them significantly less damaging to those who use their computers for things other than web browsing.
What I always found is that if I forced Safari to quit, it would free up half the available RAM (512MB macmini Core Duo) and the numbers would go significantly down in the virtual memory area. This asks the question, is safari keeping all windows and tabs, including history in memory at all times? Why is it not released when tabs are closed?
Actually that might be my one real complaint with the Mac is the memory management, It’s fast in everything except Safari, where it is only fast for the first few hours of operation. It gives the impression of paging out a lot.
March 1st, 2007 at 4:07 pm
with 3 safari windows open (15 tabs, 2 tabs, 5 tabs):
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
281 Safari 1.2% 97:55.73 29 645 3454 559M 79.6M 605M 1.32G
then relaunch (with SafariStand restoring everything exactly as it was):
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
3314 Safari 0.3% 1:15.78 10 169 775 92.7M 58.7M 132M 523M
system-wide slowness cured. same pages open. memleak?
March 1st, 2007 at 5:03 pm
How about setting CPU usage for plugins to near zero for non-active users?
I have a computer that is used by multiple members of my family, with user switching.
I often find that the system is running very slowly, and checking the activity monitor, it turns
out that the Safari process for a switched out user is running at 80% CPU utilization, typically due
to some animated GIF or flash plugin.
March 1st, 2007 at 7:21 pm
[...] 篇新聞指Safari明顯有Memory Leak的問題。Safari的開發團長Dave Hyatt表明會盡快修正。他聲稱Safari的問題和Safari本身及Webkit（Safari的引擎）無關，這是和Plug-in，以 [...]
March 1st, 2007 at 8:52 pm
Off topic, but a safari issue regardless, with a reward if anyone knows the answer. I’ll give away a $50 version of CrushFTP is someone can help me solve an XML / javascript security issue with Safari. I cannot make XMLHTTP requests from web pages that were generated with XML / XSLT. That’s it. If you can solve that issue, CrushFTP 50 user is yours.
http://www.crushftp.com:81/ login demo, pass demo will not work with browser uploader.
http://www.crushftp.com:82/ login demo, pass demo, does work just fine since its HTML based and not XML based.
I’m trying to use XML to speed things up in safari…that’s why I ran into this article, and hence my issue. I can’t have speed and Ajax at the same time.
–Ben : ben@crushftp.com
March 1st, 2007 at 9:52 pm
Piling on the memory issue. On my 1GB MBP, the OS + Safari => 250-300MB free. That goes very fast.
On my wife’s 500MB Mac Mini, Safari + OS + anything else => paging and a virtual shutdown of the windowing system. Yes, 500MB isn’t a lot, but it’s a system Apple sells, and it barely works. Once the system gets to that point, btw, quitting Safari normally take several minutes. She has to keep a Terminal window open to run ‘kill -9′.
March 1st, 2007 at 11:17 pm
Internet Explorer for Mac used to do that too. And this whole time, I’d thought IE did that just so that I wouldn’t miss out on any vital frames…
March 1st, 2007 at 11:23 pm
[...] ts.pl?sid=07/03/01/144222 Links: 0. http://macenstein.com/default/archives/540 1. http://webkit.org/blog/?p=96 [...]
March 2nd, 2007 at 2:07 am
Safari has huge memory leaks. The best test I’ve found for this is dpreview.com
Go to the forum. Particularly when big photos are clicked on & viewed in the discussion threads, Safari rapidly grabs enormous chunks of RAM and doesn’t let go.
I use a little utility app called “Memory Monitor” to keep track of this. I find myself restarting Safari every couple of hours to free up RAM. No one will have the definitive word on Safari vs. other apps without taking RAM usage into account.
March 2nd, 2007 at 10:03 am
People, PLEASE:
1. Nobody is disputing that Safari, as currently released, has issues with speed and especially memory.
2. What everybody seems to be forgetting is that these issues have been fixed in the nightly build, for at least some people.
In fact, in all cases tested so far, ALL issues have been fixed.
Unfortunately, there has only been one case tested so far, Dr. Macenstien…..
3. Could everybody who has noticed issues in the past, and cares enough to write in, please take the next step and try a nightly and let everybody (and Dave, particularly) know if the problem remains, and be specific etc. etc. if it hasn’t.
It wouldn’t hurt to say “nice work” if the problem has been fixed, also, in the interest of balance.
sheesh.
Glenn
March 2nd, 2007 at 1:54 pm
Glenn, I’ve submitted 10s on bug reports to apple with 3 or 4 bugs with html list, javascript source code and ways to reproduce the bugs along with what the expected behavior should be (these were all XML / DOM bugs). I’ve done it a while ago (many releases ago). The fact that no one them have been fix even though you can read about them everywhere on the internet just proves that apple doesn’t care … so neither do I
March 2nd, 2007 at 2:11 pm
JavaScript Timing, Nothing Under 10ms
Tobie Langel pulled out an interesting little JavaScript nugget from the recent Background Music post on Webkit/Safari Blog:
Some Web pages specify repeating timers with an extremely small timeout. In fact they often use the value 0 to mean “Fire as…
March 3rd, 2007 at 3:29 pm
”
I think folks may misunderstand how memory is used on Mac OS X. The basic premise is that empty memory is wasted memory. So far I see complaints about this max value and that max value which isn’t likely relevant given that memory is attempting to be used to its fullest as a cache (often backed by files on disk allowing quick recycling of pages used for caching). The issue to look for is active / continuous paging to disk. If you see this then you maybe more justified in stating a problem exists.
”
Spare us the condescension. This is not a forum populated by newbs who don’t understand VM.
There are VERY REAL problems with Safari’s memory usage, as plenty of people have pointed out.
There is indeed massive use of REAL memory, leading to paging. There also appears to be massive fragmentation.
the bottom line is that if you leave Safari running for long periods of time (say weeks), and if you frequently open plenty of pages (say a hundred or so a day), you will indeed get to s situation where
• Safari is really slow doing anything and
• it is using up vasts amounts of REAL memory and
• switching Safari from background to foreground generates massive paging (on a 1.25GB machine) and
• shutting down Safari takes minutes as it carefully runs through bazillions of chains of fragmented data structures doing god knows what, rather than simply killing its heap.
So why run Safari for weeks without restarting it? Well
(1) Safari doesn’t save its state so restarting it is incredibly painful if you have more than three pages open.
(2) We are not living in 1991. I expect the computer to damn well do what I want, not that I should have to structure my life around what it wants. I want Safari to run all the time; and I want it to crash less; and I want it to store to disk a record of its state once a minute so that when it is shut down or does crash, it restarts with the same state it had. I don’t expect to have to reboot the OS every two days to keep it running safely, and I don’t have to manually type sync every hour to be sure the file system is safe on disk; so why should I have to put up with this sort of crap when it comes to an application?
March 5th, 2007 at 12:50 pm
I won’t disagree about the forgetting of tabs upon quit, but there are SIMBL plug-ins that do that, like ForgetMeNot:
March 5th, 2007 at 12:52 pm
Hmmm, somehow edited out the link I put in:
http://kisonecat.com/software/forget-me-not/
March 6th, 2007 at 5:01 am
Timer resolutions and browsers
On Surfin’ Safari David Hyatt recently posted on the topic of Background Music. One of the tidbits from that post - which really has only tangential coverage of background music - reads as follows:Some Web pages specify repeating timers with an extre…
March 6th, 2007 at 9:53 am
Guys, check out the Aperture website: http://www.apple.com/aperture/
There’s a big JavaScript slideshow which plays slow and stuttered in Safari, Shiira, Omniweb (all using WebKit). In Firefox, it just flies. Is this a bug in the WebKit JavaScript engine?
March 6th, 2007 at 1:51 pm
[...] when it should be idle: Surfin’ Safari - Blog Archive Background Music
[...]
March 6th, 2007 at 4:28 pm
[...] JavaScript timeouts precisely; Firefox and Safari 3 don’t allow timeouts under 10ms. read more | digg story ~ by junioz on March 6, 2007. Leave a Reply [...]
March 7th, 2007 at 9:01 am
Congrats on passing the 20000 mark, if it is at all significant to anyone.
March 7th, 2007 at 10:00 am
While I have nothing against the idea of Safari being able to run smoothly in perpetuity without restarting, I would question the need to keep your computer running constantly. There are only a finite amount of natural resources - it’s not a bad idea to conserve some when you can.
March 8th, 2007 at 12:16 am
“The Mac plugin framework is really archaic (in Safari and Firefox).” So I understand there is no need to blame Adobe for the performance problems with the Flash plugin. I thought a new type of web plugin, different from Netscape plugins, had been introduced with Mac OS X and/or Safari. Any project to fix this?
March 8th, 2007 at 6:28 am
WebKit supports the WebKit plugin API as well as the Netscape plugin API. As Firefox only supports the latter, the majority of plugins for Mac OS X use the Netscape API so as to support as many users as possible. One exception to this is the QuickTime plugin which is installed as both a WebKit and Netscape plugin in recent versions of Mac OS X.
From what I have seen the plugin API used by the Flash player isn’t relevant to many of the performance issues that people have with it. There are other equally annoying issues such as excessive repainting of unchanged content which chews CPU unnecessarily. One pathalogical case is an HTML document with 10 or 15 YouTube videos embedded in it. YouTube videos load and display a static image until the user clicks on the play button. Somehow the Flash plugin manages to spend ~30% CPU time redrawing these 10 or 15 static images, even though nothing is actually changing. I’ve filed bug reports with Adobe on some of these issues, here’s hoping they’re fixed in future updates.
One benefit of the Flash plugin switching to the WebKit plugin API is that the plugin would be in control of its idle handling, so background CPU usage would be entirely in Adobe’s hands. This can be a positive or negative, depending on how you look at it.
March 8th, 2007 at 11:28 am
I appreciate all the careful thought to how to handle background processing, but I’d really rather have it off. All the animations I see are ads. It’s bad enough for them to take resources while I’m watching the page. I certainly don’t want them doing it while I’m not.
I’m also getting tired of having Safari slowly degrade in performance, impacting the rest of the system.
I hope I don’t sound negative. I really like Safari. But I’m slowly moving to other browsers because of Safari’s impact on the system, and its insistence on my installing Flash even though I don’t want it. (Yes, I know there are shareware products for this, but my experience is that shareware system tools eventually cause more trouble than they solve.)
March 8th, 2007 at 1:52 pm
I know this is the wrong forum.
As a newbie I need help as I am unable to build and run the webkit. Where does one go ?
Thanks in advance
March 8th, 2007 at 6:10 pm
dilbertfan: Please take a look at the “Keeping in Touch” link in the navigation to the left. The easiest forum for getting help would be the IRC channel, as this is real-time chat with many of the WebKit developers.
March 12th, 2007 at 4:02 pm
”
While I have nothing against the idea of Safari being able to run smoothly in perpetuity without restarting, I would question the need to keep your computer running constantly. There are only a finite amount of natural resources - it’s not a bad idea to conserve some when you can.
”
(1) Modern computers have this crazy new invention called “sleeping”. Look into it some time.
(2) Do you have no kids and a vasectomy? I do. If you don’t, then WTF right do you have to tell other people about saving natural resources? Any kids you bring into the world will utilize VASTLY more resources than my sleeping TiBook portable.
March 14th, 2007 at 6:39 am
name99, please try and keep the discussion relevant to the topic at hand and avoid making a technical discussion into a personal one. What you may interpret as condecension is likely the fact that any user of a WebKit-based browser may be participating in this conversation, not just those whom are technically inclined. It’s very difficult to know what level of knowledge to assume when composing a response in a situation such as that. Simplifications and explanations are provided so that those not intimately familiar with how things work can at least follow along, and to ensure that everyone is on the same page.
- Mark
March 18th, 2007 at 11:13 am
“The Mac plugin framework is really archaic ” So I understand there is no need to blame Adobe for the performance problems with the Flash plugin. I thought a new type of web plugin, different from Netscape plugins, had been introduced with Mac OS X and/or Safari. Any project to fix this?
March 20th, 2007 at 10:27 am
[...] owser should do when it is the background application is actually … Original post by hyatt
No Comments yet
»
RSS feed for comments on this post [...]
March 24th, 2007 at 2:53 am
I won’t disagree about the forgetting of tabs upon quit, but there are SIMBL plug-ins that do that, like ForgetMeNot:
March 29th, 2007 at 5:18 pm
[...] Several bugs exist, performance and otherwise. Apple and the Safari team even admit to an “archaic Mac plugin framework” yet we hear nothing from them on plans to address this issue. One such [...]
May 22nd, 2007 at 4:06 pm
[...] around the blogosphere on the "Sluggish Safari" issue including a response from Surfin' Safari's David Hyatt, one of the engineers responsible for creating and updating Safari: 1) Browsers [...]