I have an iPhone app (Objective C++). My beta testers - some of them, not all of them - are complaining of slow startup, 7 to 10 seconds. On my device (it's a 3GS), it loads in about 2 sec. On the device simulator - even faster. As things stand now, I cannot even isolate the bottleneck.
Can I somehow slow down the simulator or a fast device? Setting the simulated hardware version to 2.0 does not help.
As a last resort, I could try and borrow an old, slow device from a friend for a night or two. But I'd rather not...
If I were you I'd try profiling the startup with Shark - it's hard to profile startup on the device, one way is to put a 5-6 second sleep statement in ApplicationDidFinishLaunching so you have time to attach Shark and start recording, don't make it too long though or the app will be killed!
Also consider what you are doing on startup that might be a lot longer for some people - looking at address records, or things like that.
Aral Balkan links to some nice tools by Mike Shrag that allow you to get the old slow motion simulation mode on triple shift working in SDK 3. Speedlimit - which allows you to throttle network bandwidth might be useful.
This is an old question, but one option is to use a non-SSD iMac or MBP to test on a slow environment. The latest Xcode versions and simulators (XC version 7 for sure) run extremely slowly on non-SSD devices. More slowly than any actual phone...
Related
Currently i don't have an apple developer account ($99).
I am developing iOS app with searching function in iOS Simulator.
In simulator my app's search speed is not bad, just normal.
But when i check my app for memory leaking with Instrument tool, my app's search speed is too slow and data load speed are also too slow.
I have to load 30 MB data in Start of app.In Simulator it's fast.But in Instruments , it's too slow and also took 6 seconds.
So i am worring about my apps to run on physical devices because of speed.
I would like to know , Is the iPhone physical device faster than Instrument tool's check memory leaking?
In my experience, normal execution on iPhone is much faster than profiling with Instruments. But, that heavily depends on the application and what "instrument" are you using. If your application does a lot of memory allocations, it will be very slow when using Instruments with "Allocations" settings.
But also be prepared, that the iPhone Simulator is usually much faster than the real device. Your desktop CPU is usually x86 and over 2 GHz, but the device's parameters are lower. And also the architecture (ARM) makes the code to be compiled into more instructions than on x86, which also makes it a little bit slower.
Anyway, you really should just go ahead, buy the developer account and test your app on the device, there's no other way to predict the performance. I guess the rule in your situation should be don't guess, measure.
Please dont guess anything test on real device go an buy $99 developer account. iPhone Simulator is usually much faster than the real device. Its a very bad idea to download 30 MB of data at the start. If connection is slow it will take more than 5 min. If your data on device goes more tnan 45 MB apple will kill your applicationa nd free the data. Make sure you are doing in write way.
I am in the last phase of my iphone game development: optimization and performance tuning. My problem is, the game runs quite smooth on iphone 4 and iPad, but it often crashes on iPhone 2 with iOS 3.1.3 due to low memory.
I have gone through all the memory leak detection / clean up processes, and the Xcode instrument shows no leak except those from system library (see following screenshot). I also use "autorelease" rarely.
(bigger picture: click here)
I also profiled my application using "CPU Sampler" and "Allocations", but is a little confused by the result. This is the result from "Allocation" benchmark:
(bigger picture: click here)
This is the result after one game. As you can see, the "Live Bytes" is only 3.93MB, which shouldn't be a big deal (according to my understanding) -- but the game often crashes at this time on iPhone 2, ios 3.1.3 .
I also did a "CPU sampler" benchmark, following is the result:
(bigger picture: click here)
What confused me is, the real memory shows "22.32MB" and the virtual memory is more than 100MB, which is dramatically different from the result of "Allocation benchmark".
I am also confused by the fact that, my iPhone 3G, running iOS 4.1, even if it has almost exactly same hardware spec with iPhone 2, can run my game very well. It's slow and not as snappy, but it rarely crashs.
So my questions are:
What else I can do to identify the low memory issue on iphone 2?
Are the leaks from system libraries on the "Leaks" profiling result a problem?
Why "CPU sampler" and "Allocation" shows different memory foot print? Did I read them correctly?
Why iPhone 3G runs a lot more smoother than iPhone 2G? Is it because the newer iOS version (4.1 vs 3.1.3)?
1. What else I can do to identify the low memory issue on iphone 2?
Run your app in iOS simulator and use Hardware menu item "Simulate Memory Warning" item to trigger Out-Of-Memory events in places, which you suspect to crash.
Instrument your app in real device, but before launching it start as many other apps as possible to reduce amount of available memory. While running your app, switch every now and then back to app grid to (re)launch other apps. This way you will make system generate genuine Out-Of-Memory events, but you can't choose which app will receive them.
You could generate OOM events by yourself, but then you would be running a different application. Might be useful, while developing, but not recommended when close to release. Very annoying to debug bugs caused by debugging "helper" routines...
2. Are the leaks from system libraries on the "Leaks" profiling result a problem?
They could be side-effects of your code. Look around which part of your app might be starting that system service and whether you release / cancel / close everything.
3. Why "CPU sampler" and "Allocation" shows different memory foot print? Did I read them correctly?
No idea, but would like to know :)
4.Why iPhone 3G runs a lot more smoother than iPhone 2G? Is it because the newer iOS version (4.1 vs 3.1.3)?
iPhone 3G has better, faster and more hardware than iPhone2. As result, apps seem to run faster... which can be a problem, if your app runs too fast in faster hardware. Making sure your app runs "just right speed" regardless of hardware is a different question.
Any thoughts on why this code runs slow on device but fast on simulator in iphone, I am making a game in cocos2d, and I am moving an object from one place to another , throught CCTouchBegan , CCTouchMoved, CCTouchEneded (ccp function) and after that I take the action on it,
can any buddy tell me what is the main issue to solve this problem,
The simulator is a simulator not an emulator. All the simulator really does is provide a window for running an iOS app. You'll notice that when you build for the simulator, the system architecture is set to i386. You're compiling for the Mac when you use the simulator. There's no memory restrictions, sandboxing etc. In fact, I think your app even shows up as it's own process.
That's why when you run it on the device, you get hammered. You just have to work on optimizing your code. The simulator is terrible. Just use your device for debugging, it'll save you the confusion. If you post your code, we might be able to help you speed it up.
Happy coding.
The basic hardware of the computer on which the Simulator runs and that of an iOS device are very different, from CPU clock speed, to instruction parallelism, to branch prediction, to cache size, to memory bandwidth, to memory available. The possible compiler optimizations might also be different, given the different ISAs. It's not uncommon for general code to run an order of magnitude faster on the Simulator on a Mac than on an iPhone.
There can be many reasons like (also) #simulator vs actual device
Low Memory can be the first problem as in your actual device as you will install different kinds of huge applications but in case of simulator you will not install t.
Low power problem as the actual device will be powered by battery and not like simulators which get constant power all the time.
Other application interfering with your application run cycle but in simulator you will hardly run any application while you are testing your application.
You cannot see the UserInterface(UI) as clear in your MAC as you can see in your actual device, so which appears correct may not be actually correct.
Application interfered by calls, in simulator this type of interference will never happen.
I've tested my app thoroughly on the simulator, but I don't have an iphone/ipad/ipod touch on which to test the app. Are there likely to be bugs that dont expose themselves until I test it on the device?
if i had a macbook, id take my code along with me and meet up with a friend or a stranger to test the app, but im working with a mac mini :(
Thanks for the input.
The one major concern is performance. Devices, especially older ones, have orders of magnitude worse performance than Mac mini, both in terms of CPU and memory. It is possible that your app is crazy slow on a device, yet runs fine in simulator.
Other areas to think about:
network connectivity, performance in poor/no network conditions (good way to test in simulator: yank out ethernet/turn off airport... but some reachability code works differently in device and simulator I think, and you cannot simulate mobile-only [no wifi] situation)
As Rengers said, you should get your friends' device IDs and then create a provisioning profile so they can run the test version of your app which you can e.g just zip up and email to them.
You will really want to pick up a device, an iPod Touch isn't that expensive, and you can even get iPhone 3GSs for less than $100 now at some retailers (contract required). The reason for this is that there have been many cases of the simulator doing one thing while a device does another, in addition to the resource differences (both in terms of available cpu time and memory)
Yes, there are bugs that will only show on the device. It depends on the complexity of your app. For a fairly simple application, chances a bug will show up on the device only will be a little lower.
However, I strongly recommend to test on the device. Bugs aside, you can't get a good measure of performance on the simulator. A real devices has much tighter ram and cpu constraints.
If you have a developers account, afaik you can distribute apps to testers. Perhaps someone else with an 'iDevice' is willing to test for you?
Not so long ago iPhone development was quite simple, only a few OS versions and even less devices.
Now however, there are 2 major OS versions and 5 different devices to consider.
As a company about to release several applications testing has been become more and more of an issue.
What are the best ways to test all combinations, do I need to acquire every generation of iPhone and iPod Touch? Are there any gotchas with specific hardware/OS combinations I might need to code around?
I guess my question is, "What's the minimum amount of testing required to cover all the bases?"
In my experience, you won't have much compatibility trouble between iPod/iPhone. There are other gotchas to be aware of:
The devices run at different speeds. iPhone v1 and iPhone 3G run at 412MHz; iPod Touch runs at 532MHz, and the new 3GS runs at 600MHz. This can have a big impact on performance and even functionality if you're getting fancy.
There's a huge performance difference between EDGE/3G/WiFi networks; often the differences are counter-intuitive. EDGE can often have better latency (time to first byte) than 3G, while 3G has 10x better bandwidth. You'll want to test your app under all three conditions.
Are you using Core Location? iPhone v1 and iPod Touch do not have GPS.
Are you using the camera? The iPod Touch does not have a camera.
Is your app compatible with jailbroken phones? A lot of people have done it, and if your app crashes on them, they will blame you, not the Dev Team hackers, and this will be reflected in your App Store ratings. Note especially that background apps can use up memory that you might have thought would be available exclusively for your app. Leave yourself some overhead.
So, what do you need to buy? If you're a serious developer, yes, you should have all 5 devices available. But do you need to test every build on all 5 devices? Does every one of your developers need 5 devices each? No.
One developer can probably test everything that matters with one iPhone 3G and an iPod Touch. Toss in a 3GS and your coverage is probably nearly perfect. (Note that development on 3GS is much nicer just because the CPU is faster, so your apps deploy more quickly.)
At work we have one device per developer, but they're a mix of 3G and iPod devices (and, today, one 3GS).
I don't have much experience with the iPhone itself, but in general this might be a good application of pairwise testing. In practice, you can get 90% coverage with a small fraction of the testing of an exhaustive test pass. Then later if you find certain configurations have gotchas you can add them to your set of configurations and still not need to do an exhaustive pass.
I am not sure if its a best practice.
But I have heard many people using ibetatest for exactly what you are looking for. Lots of enthusiastic beta testers out there.
You shouldn't have any issues on 95% of your code running on different versions, and something like ibetatest should catch the remaining 5%.
Get all the combinations is the short answer.
I started out with just the iPod, but it's 100MHz
faster than the previous iPhone model. My app's
performance sensitive, so I'm gonna have to get
an old iPhone. I can hardly ask my beta testers
(volunteers?) to run the GL performance tool.
I'd suggest a couple things:
you probably will need a range of devices for your own internal testing. As has already been pointed out, there are various differences between each generation of iPod Touch/iPhone
you may want to look into using crowd-sourcing to supplement your internal testing. This potentially allows you to have a bigger audience to test your apps and any cost of using crowd-sourcing is potentially offset by the fact that you can spend less on devices and potentially less on internal testing staff and at the same time, potentially producing a better product. One crowd-sourced test group not mentioned above is uTest.com