Could you also test http://nin.com/ (see my first set of benchmarks in the other thread)? Does it crash - particularly if you scroll around?
----------
Another set of benchmarks added: https://forums.macrumors.com/posts/18504947/
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Are iOS 7 & the A7 processor stable?
- Thread starter pr0230
- Start date
- Sort by reaction score
Could you also test http://nin.com/ (see my first set of benchmarks in the other thread)? Does it crash - particularly if you scroll around?
----------
Another set of benchmarks added: https://forums.macrumors.com/posts/18504947/
I've been getting about one respring a week on my 5S. I'm hoping iOS 7.1 should fix that right up.
It's not a RAM issue. My iPhone 4S and iPad 2 are always out of RAM, but they don't respring. Individual apps may close more often, but Springboard crashing is probably some iOS 7/A7-only bug.
It's not a RAM issue. My iPhone 4S and iPad 2 are always out of RAM, but they don't respring. Individual apps may close more often, but Springboard crashing is probably some iOS 7/A7-only bug.
I'm not even sure that is remotely fair. Chrome 30 something on my Win7 box, that nin.com tab eats 436MB!
Broken websites, are just that, broken and ******.
Last edited:
I don't get it! I have everything on, motion, 3G, GPS and I don't have crashes! In one month of usage, it crashed 1 time!
About the safari tabs I can't say much because I usually don't have many open!
Multitasking, I can have more than 5 apps open and when I switch back it's still where I left it and doesn't reload, it's a big improvement from the 4S!
The only device I notice that struggles with iOS 7 is the iPhone 4! But I'm confident apple will fix it like they fixed the 3GS on the 6.1.3 because it was unusable on iOS 6
About the safari tabs I can't say much because I usually don't have many open!
Multitasking, I can have more than 5 apps open and when I switch back it's still where I left it and doesn't reload, it's a big improvement from the 4S!
The only device I notice that struggles with iOS 7 is the iPhone 4! But I'm confident apple will fix it like they fixed the 3GS on the 6.1.3 because it was unusable on iOS 6
It's NOT broken. It's just that it's full of images and videos and, consequently, it uses a LOT of memory. As you've mentioned, also on the desktop.
BTW, with NIN, I've made some OS X-based measurements:
Firefox: 229M (with blocked Flash) / 159M (with non-blocked Flash)
Safari: 477.5M
As you can see from the above figures, generally, Safari seems to be using more memory on OS X to load the same page than Firefox. With my standard benchmark suite at http://winmobiletech.com/a/1.html , the above figures are as follows:
Firefox: 25M
Safari: 28.9M
----------
Probably they just stop loading right after receiving the first memory shortage warning to avoid the impending crash. Then, UIWebView almost never crashes but, of course, doesn't load the entire page (or all inline resources). Depending on where it stopped (for example, are all CSS files loaded), the end result may not seem to be only partially loaded.
(BTW, one can easily check this out with the second version of my benchmark suite. As I've explained at https://forums.macrumors.com/posts/18504947/ , in the new version I immediately cancel download from the low memory callback (didReceiveMemoryWarning). If one does receive a warning (easily to see as the warning is also printed to the console), then, it's easy to check out what a partially-loaded version of nin.com looks like.)
EDIT (12/19/2013 15:51 GMT): this post is based on wrong results; please ignore it. I only keep it intact for historical purposes. See https://forums.macrumors.com/posts/18522600/ for the update.
Original post:
Guys,
today, I've made some serious comparative tests to find out whether the claim of several MR forum members are true.
Many have stated the latest beta, beta 2 of iOS 7.1, have fixed the memory / Safari crashing problems. An example of these claims is at https://forums.macrumors.com/posts/18510004/ : there, forum member MikhailT stated "There are still some sites that crashes Safari but the good news is that the apps using WebView are no longer randomly crashing as they were before in iOS 7.0.x." Exactly this is what I'm going to scrutinize here (after all, my tester app does use UIWebView) - and prove it's, unfortunately, not exactly right.
Well, guys, I have some bad news: there don't seem to be any kind of a crash improvement. To properly test this, I've further extended my simple tester Web browser. (Sources: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/WebPageMemoryTester3.zip ) Basically, the new version divides the screen into two and loads the same nin.com to both (upper and lower) halves. It loads the upper one first and starts loading the lower one only after waiting 30 seconds.
This results in double the memory usage compared to the previous version(s). The previous version, as you may recall, only loads one Web page, which means it won't crash if you load, say, nin.com page on an iPhone 5, 5c or 5s with 1 Gbytes of RAM, particularly if you do this after a reset, without no other apps (daemons) running in the background. (The same doesn't apply to 1 GB RAM-equipped Retina iPads, which, generally, immediately crash already during loading the page.)
This fact allows for stability / crash testing on these 1 GB iPhone models. With nin.com and 650...720 Mbytes of free (initial) RAM, as is the case on the iPhone 5 running both iOS 7.0.4 and iOS 7.1 beta 2, both panes will be fully loaded and it's "only" during scrolling around the two panes that the app will fully crash. And it will crash – always. Yes, even under iOS 7.1 beta 2.
This means crash protection because of running out of memory during scrolling is in no way implemented in iOS 7.1 beta 2 either. iOS 7.1 is as fragile as it was before, unfortunately.
(Some runtime memory figures on the iPhone 5: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/704ip4.txt ; first with 7.0.4 and, then, with iOS 7.1 beta 2. Both were clean installs, without restoring any kind of backups. No iCloud was configured; absolutely no background apps run. See my previous comment at https://forums.macrumors.com/posts/18504947/ on the format of the list.)
Original post:
Guys,
today, I've made some serious comparative tests to find out whether the claim of several MR forum members are true.
Many have stated the latest beta, beta 2 of iOS 7.1, have fixed the memory / Safari crashing problems. An example of these claims is at https://forums.macrumors.com/posts/18510004/ : there, forum member MikhailT stated "There are still some sites that crashes Safari but the good news is that the apps using WebView are no longer randomly crashing as they were before in iOS 7.0.x." Exactly this is what I'm going to scrutinize here (after all, my tester app does use UIWebView) - and prove it's, unfortunately, not exactly right.
Well, guys, I have some bad news: there don't seem to be any kind of a crash improvement. To properly test this, I've further extended my simple tester Web browser. (Sources: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/WebPageMemoryTester3.zip ) Basically, the new version divides the screen into two and loads the same nin.com to both (upper and lower) halves. It loads the upper one first and starts loading the lower one only after waiting 30 seconds.
This results in double the memory usage compared to the previous version(s). The previous version, as you may recall, only loads one Web page, which means it won't crash if you load, say, nin.com page on an iPhone 5, 5c or 5s with 1 Gbytes of RAM, particularly if you do this after a reset, without no other apps (daemons) running in the background. (The same doesn't apply to 1 GB RAM-equipped Retina iPads, which, generally, immediately crash already during loading the page.)
This fact allows for stability / crash testing on these 1 GB iPhone models. With nin.com and 650...720 Mbytes of free (initial) RAM, as is the case on the iPhone 5 running both iOS 7.0.4 and iOS 7.1 beta 2, both panes will be fully loaded and it's "only" during scrolling around the two panes that the app will fully crash. And it will crash – always. Yes, even under iOS 7.1 beta 2.
This means crash protection because of running out of memory during scrolling is in no way implemented in iOS 7.1 beta 2 either. iOS 7.1 is as fragile as it was before, unfortunately.
(Some runtime memory figures on the iPhone 5: https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/704ip4.txt ; first with 7.0.4 and, then, with iOS 7.1 beta 2. Both were clean installs, without restoring any kind of backups. No iCloud was configured; absolutely no background apps run. See my previous comment at https://forums.macrumors.com/posts/18504947/ on the format of the list.)
Last edited:
Nobody said it resolved the crashing for Nin.com site.
The improvements have nothing to do with adding crash protection or anything like that, it had to do with improving the memory leaks in Safari in typical usage.
Dozens of beta testers have confirmed that Safari has stopped crashing daily during typical usage and other apps that uses the in-app UIWebView. The same thing that I said in my post there. I have only experienced one crash and nothing else since beta 2 was released after practically a week of usage.
That is compared to 2-5 crashes daily in Safari, other apps, SB re-springs, and so on in 7.0.x series. Also, daily low memory reports in my diagnostics area from dozens of apps. In 7.1 beta 2? Nothing.
Your testing is too specific to a known problematic site and doesn't describe the actual noticeable major improvements that everybody is seeing.
Yup, you're right. I've just finished another set of hardcore tests with my, since yesterday, vastly enhanced benchmarker app, routinely flashing my GSM A1429 iPhone5 between 7.0.4 and 7.1b2, without any iCloud / AppStore login / backup restoration. During this, I've also confirmed 7.1b2 has a significantly less crash-prone UIWebView implementation than 7.0.4. The previous, two-pane version of my tool couldn't tax the iPhone 5 fully; hence the wrong results I got yesterday.
The new benchmarker tool to allow for
- manual page loading initialization (the last one was hard-wired to start loading the second tab exactly 30 seconds after the first)
- using any number of on-screen tabs (configurable)
The full sources of the new version are at https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/MultiPaneWebBrowserMemChecker.zip . You may want to change the following to fine-tune it:
- the URL to load in (void)respondToTap: (UIButton *)recognizer
- the number of tabs: int NR_OF_WEBVIEWS = 6;, in – (void)loadView. Again, you can change this to any value.
Both in MultiPaneWebBrowserMemCheckerViewController.m
The app is Universal and works full-screen on the iPads too. Note that I haven't done direct 7.0.4 vs. 7.1b2 on iPads; will definitely do tomorrow and post an update.
NOTE: page loading must be manually started for each tab individually, by tapping the grey button label on the left. (Also see the screenshot at the bottom of my post.)
Just like yesterday, I've tested
- http://nin.com – a video/image-packed page with very heavy memory usage
- http://winmobiletech.com/a/1.html – my standardized benchmarker homepage since 2005 with moderate memory usage
- http://www.reliply.org/tools/requestheaders.php - just a lightweight page
7.1b2 indeed seems to have considerably better memory usage than 7.0.4 on the 32-bit iPhone 5.
With nin.com, I in no way could load more than three tabs under 7.0.4. After loading the first three, all attempts to load the fourth have resulted in a crash during loading. Some example memory dumps are at https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/NEW 704 iP5 loading only 4 tabs.txt
Of course, scrolling already-loaded pages, assuming there were three of them (so that there was little free memory left – around 100 Mbytes after finishing the loading of the three instances of nin.com) has also resulted in an almost-immediate crash in all occasions. Some examples of these logs are in the log file at https://dl.dropboxusercontent.com/u...webView/NEW 704 iP5 scrolling only 3 tabs.txt
Under 7.1b2, I had no problems with loading (and keeping in memory) even six fully loaded tabs of nin.com. I've never encountered crashes during loading them. It's only during scrolling, after loading the six tabs, that I've encountered crashes. It did crash on every occasion. With four, fully-loaded tabs of nin.com, however, I've never been able to crash 7.1b2. An example dump is at https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/NEW 71b2 iP5.txt , showing the results of test runs using both 4 and 6 tabs and with scrolling under both. For example, the 4 tab + scrolling dump is right at the beginning. (See the in-dump remarks in the file.)
All in all, the improvements are indeed significant.
An image showing all six tabs loaded under 7.1b2. I've also scrolled around a bit in all the six tabs (immediately after taking the screenshot and continuing scrolling, the app has crashed):
The new benchmarker tool to allow for
- manual page loading initialization (the last one was hard-wired to start loading the second tab exactly 30 seconds after the first)
- using any number of on-screen tabs (configurable)
The full sources of the new version are at https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/MultiPaneWebBrowserMemChecker.zip . You may want to change the following to fine-tune it:
- the URL to load in (void)respondToTap: (UIButton *)recognizer
- the number of tabs: int NR_OF_WEBVIEWS = 6;, in – (void)loadView. Again, you can change this to any value.
Both in MultiPaneWebBrowserMemCheckerViewController.m
The app is Universal and works full-screen on the iPads too. Note that I haven't done direct 7.0.4 vs. 7.1b2 on iPads; will definitely do tomorrow and post an update.
NOTE: page loading must be manually started for each tab individually, by tapping the grey button label on the left. (Also see the screenshot at the bottom of my post.)
Just like yesterday, I've tested
- http://nin.com – a video/image-packed page with very heavy memory usage
- http://winmobiletech.com/a/1.html – my standardized benchmarker homepage since 2005 with moderate memory usage
- http://www.reliply.org/tools/requestheaders.php - just a lightweight page
7.1b2 indeed seems to have considerably better memory usage than 7.0.4 on the 32-bit iPhone 5.
With nin.com, I in no way could load more than three tabs under 7.0.4. After loading the first three, all attempts to load the fourth have resulted in a crash during loading. Some example memory dumps are at https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/NEW 704 iP5 loading only 4 tabs.txt
Of course, scrolling already-loaded pages, assuming there were three of them (so that there was little free memory left – around 100 Mbytes after finishing the loading of the three instances of nin.com) has also resulted in an almost-immediate crash in all occasions. Some examples of these logs are in the log file at https://dl.dropboxusercontent.com/u...webView/NEW 704 iP5 scrolling only 3 tabs.txt
Under 7.1b2, I had no problems with loading (and keeping in memory) even six fully loaded tabs of nin.com. I've never encountered crashes during loading them. It's only during scrolling, after loading the six tabs, that I've encountered crashes. It did crash on every occasion. With four, fully-loaded tabs of nin.com, however, I've never been able to crash 7.1b2. An example dump is at https://dl.dropboxusercontent.com/u/81986513/122013/14UIwebView/NEW 71b2 iP5.txt , showing the results of test runs using both 4 and 6 tabs and with scrolling under both. For example, the 4 tab + scrolling dump is right at the beginning. (See the in-dump remarks in the file.)
All in all, the improvements are indeed significant.
An image showing all six tabs loaded under 7.1b2. I've also scrolled around a bit in all the six tabs (immediately after taking the screenshot and continuing scrolling, the app has crashed):
Awesome, I'm glad to hear that. Great adjustments to your tools. It seems like there's some kind of buffer issue. As you scroll down, it just can't handle it anymore. I'm not familiar with how the rendered page is loaded, do Apple take advantage of storing many of the images in the GPU's buffer or are we not there yet? I know some of the image decoders are still CPU based of which is difficult to move to GPU.
Please don't forget to send all of your data to Apple, I'm absolutely sure they'll love to have it.
If you need us to duplicate it to get it noticed by Apple, let us know the OpenRadar ID.
Thanks!
No cuz the 1 gig of ram provided is not sufficient to properly run the graphics and architecture of x64
Yeah I can't figure out why they don't support their idevices as long as competing Android phones. Like why doesn't the iPad 2 run ios 7? It's only like 3 years old!