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.
General I don't understand something
- Thread starter FatPuppy
- Start date
- Sort by reaction score
I'm probably completely wrong but I think it's code that checks for crashes and bug and sents it to Apple so they can fix them.
It is BS used by those that don't know better to justify lengthy animations and other performance issues.
Such threads have never caused a noticeable reduction in performance in past betas. In the past, the performance of the final "gold master" release has always been virtually identical to the performance in the late/final betas. There is no magic "switch" that will instantly improve performance between the last beta and the GM release.
I don't code on iOS devices so I'll defer to those who do. However, in my world I have compile options that will bind settings into the object that control error messaging, error message handling, and the ability to step into the code to help debug. These settings can and do affect performance.
It's not BS. You obviously don't know what you're talking about. Do you know anything about how Apple does iOS beta testing? And have you used previous iOs beta versions and then GM afterwards?and there is no magic "switch" but there are certainly things that make the software slower like the debug code.
You say it is BS and it's used by those that don't know better but BS is what you said.
Every one in recent years.
Run any IOS benchmark now. Run any IOS benchmark after release. You will see a negligible difference. This has been the case with every final beta vs. GM in the past five years, save for perhaps one.
My hope is that Apple will adjust (reduce) animation lengths between beta and GM, but that change would have absolutely nothing to do with debug code.
Last edited:
It's often the case that developers will include additional code within a program that helps with the development and testing of the new software. These things are generally not optimised and can have an impact on performance.
Synthetic benchmarks mostly don't reflect things like lag, load times and perceptual speed. Perceived "fastness" cannot be measured by synthetic benchmarks.
Really, nothing, how did you google it??
http://en.wikipedia.org/wiki/Debug_code
Wow, yeah, debug code is BS, it's like the Loch Ness monster or the Yeti... LOL
http://en.wikipedia.org/wiki/Debug_code
"It is recommended as a best practice that debugging code be removed from production versions of applications, as it can slow them down."
Not to muddy the waters
There's also profiling code, to monitor an applications performance. There's even a WWDC session on it.
I've been a developer and have used both, but I agree in a final beta it's likely most of this work has been done and getting shut off.
There's also telemetry, but that's a separate subject.
There's also profiling code, to monitor an applications performance. There's even a WWDC session on it.
I've been a developer and have used both, but I agree in a final beta it's likely most of this work has been done and getting shut off.
There's also telemetry, but that's a separate subject.
Windows Phone was a complete redesign from Windows Mobile, internally and UI wise.
By comparison, iOS7 "redesign" is mostly visual changes that would be handled by themes on other systems, with a few extra utility things tacked on like swipe-back.
Sure, during internal development, but then (as I see that others are noting) you usually compile that stuff out before releasing your code to third party developers.
It's not considered good programming to leave in unnecessary debug code, especially if it adversely affects performance enough to be very noticeable to the user (which is the claim being made by some).
Since the op's question has been answered could I ask a brief off subject follow up question?
Could you expand or clarify this? Are you saying you physically enter additional lines of code for debug/diagnostic purposes only to remove them after testing is complete and before implementation?
Assuming we're talking about a shop that follows the SDLC, how would this work? Once the code is opened up and a single line is altered it would trigger complete regression testing.
Could you expand or clarify this? Are you saying you physically enter additional lines of code for debug/diagnostic purposes only to remove them after testing is complete and before implementation?
Assuming we're talking about a shop that follows the SDLC, how would this work? Once the code is opened up and a single line is altered it would trigger complete regression testing.
This all comes down to semantics. What is testing? What is implementation?
With my definition of those, you implement and then test. How do you test something that hasn't been implemented?
The main thing here is what you consider a "Beta" to be. Apple has acknowledged issues with each release of the Beta so far. We know in advance that it's not ready, but the focus of the Beta release to developers is not to find bugs with iOS - it's to test third party Apps.
While you'd like to be testing your Apps on something as close to the final release as possible, there are still bugs and incomplete features in the beta that mean that is just not possible. "Debug code" would put you in a similar situation.
What is "the SDLC"? There are so many out there.
I have no idea what Apple does. My earlier answer was simply to explain to the OP what "debug code" would be.
Last edited: