15

I have an app with a couple of thousand lines and within that code there are a lot of println() commands. Does this slow the app down? It is obviously being executed in the Simulator, but what happens when you archive, submit and download the app from the app store/TestFlight. Is this code still "active", and what about code that is "commented out"?

Is it literally never read or should I delete commented out code when I submit to test flight/app store?

KML
  • 2,302
  • 5
  • 26
  • 47
  • You should remove unnecessary print calls even if there is no performance impact. They end up in the device log, and you don't want to spam that log with useless info. – Matthias Bauch Feb 26 '15 at 09:59

3 Answers3

26

Yes it does slow the code.
Both print and println decrease performance of the application.

Println problem

println is not removed when Swift does code optimisation.

for i in 0...1_000 {
  println(i)
}

This code can't be optimised and after compiling Assembly code would perform a loop with 1000 instructions that actually don't do anything valuable.

Analysing Assembly code

The problem is that Swift compiler can't do optimal optimisation to the code with print and println commands. You can see it if you have a look on generated Assembly code.

You can do see assembly code with Hopper Disassembler or by compiling Swift code to the Assembly with by using swiftc compiler:

xcrun swiftc -emit-assembly myCode.swift

Swift code optimisation

Lets have a look on few examples for better understanding.
Swift compiler can eliminate a lot of unnecessary code like:

  • Empty function calls
  • Creating objects that are not used
  • Empty Loops

Example:

class Object {
  func nothing() {
  }
}

for i in 0...1_000 {
  let object = Object3(x: i)
  object.nothing()
  object.nothing()
}

In this example Swift complier would do this optimisation:

1. Remove both nothing method calls

After this the loop body would have only 1 instruction

for i in 0...1_000 {
  let object = Object(x: i)
}

2. Then it would remove creating Object instance, because it's actually not used.

for i in 0...1_000 {
}

3. The final step would be removing empty loop.
And we end up with no code to execute

Solutions

  • Comment out print and println

This is definitely not the best solution.
//println("A")

  • Use DEBUG preprocessor statement

With this solution you can simple change logic of your debug_print function
debug_println("A)

func debug_println<T>(object: T) {
  #if DEBUG
    println(object)
  #endif
}

Conclusion

Always Remove print and println from release application!!

If you add print and println instruction, the Swift code can't be optimised in the most optimal way and it could lead to the big performance penalties.

Community
  • 1
  • 1
Kostiantyn Koval
  • 8,407
  • 1
  • 45
  • 58
  • debug_println will only be optimised out if you have whole module optimisation enabled. And it needs to be within the same module (the application can't use a version in a framework) otherwise again it can't be completely optimised away. – Joseph Lord Nov 27 '15 at 15:12
7

Generally you should not leave any form of logging turned on in a production app, it will most likely not impact performance but it is poor practice to leave it enabled and unneeded.

As for commented code, this is irrelevant as it will be ignored by the compiler and not be part of the final binary.

See this answer on how to disable println() in production code, there is a variety of solutions, Remove println() for release version iOS Swift

As you do not want to have to comment out all your println() calls just for a release, it is much better to just disable them, otherwise you'll be wasting a lot of time.

Community
  • 1
  • 1
Tim
  • 8,932
  • 4
  • 43
  • 64
  • ok, I see, but just search println and replace with //println would also do the trick right. But of course if you want to leave som of it in, the solutions in your post are better more nuanced options. – KML Feb 26 '15 at 10:05
  • Yup of course, but the approaches in the answer I linked will allow you more flexibility and allow it to automatically occur when you change from debug to release builds. Good luck :) – Tim Feb 26 '15 at 10:11
0

printLn shouldn't have much of an impact at all as the bulk of the operation has already been carried out before that point.

Commented out code is sometimes useful, although it can make your source difficult to read it has absolutely no bearing on performance whatsoever and I've never had anything declined for commented out code and my stuff is full of it.

Alec.
  • 5,371
  • 5
  • 34
  • 69
  • Thank you, that is very helpful advice - it means I could just comment out all println commands and that way I will not have to worry about it. Thank you for the response ! – KML Feb 26 '15 at 09:52