0

I have to choose between one of the two in a program I'm writing in Swift but I guess it doesn't really matter what programming language I'm using.

I know String formatting is very expensive and suspect it to be more expensive than casting a Double to an Int, but I'm not even sure and most importantly, as of now, I don't see why this is the case.

Also, what I'm trying to do here is to truncate a number and print it to the console without a decimal part (meaning that I don't want it to appear like this 0.0 but like this 0). What is the most efficient way of doing that?

Could someone enlighten me?

Here is the code (String formatting on the first line and casting on the second):

print(String(format: "%.0f", sender.value))

Int(sender.value)
younes alaoui
  • 79
  • 7
  • Do you mean the whole entire code or just the formatting and casting? Because it's just basic stuff nothing fancy I guess... – younes alaoui May 10 '23 at 15:32
  • 1
    Note also that the two do different things. Formatting a double preserves the non-integral part of the value; casting to int discards it. If you actually need that part of the value, then discarding it is wrong, and it doesn't matter if it is infinitely faster, because your program is still wrong. – Brian Goetz May 10 '23 at 15:35
  • @younesalaoui Only the relevant code. But the two lines you've now posted have nothing to do with each other. Why are you comparing printing a string format versus a trivial cast? Shouldn't you be comparing two print statements or some other two comparable lines of code? – HangarRash May 10 '23 at 15:39
  • 1
    Not related to your question but if you need to get the whole part of your floating point `modf(sender.value).0` check this [post](https://stackoverflow.com/a/55010456/2303865). Btw you are not casting to Int you are coercing it. – Leo Dabus May 10 '23 at 21:25

2 Answers2

5

This doesn't answer the proximate question, but hopefully counts as "enlightenment."

The answer is: just stop worrying about micro-performance issues; about 99.999% of the time, they are a dangerous distraction. Focus instead on writing clear, readable code that is obviously correct. A program that is fast but wrong is infinitely worse than no program at all. On the other hand, a program that is correct but could be faster is still pretty darn good. When you are so good that your programs are correct all the time, then maybe it is time to start thinking about improving performance. Clear correct code can be optimized if it needs it; "clever" fast-but-wrong code can rarely be made correct without much more effort. (Case in point: your "faster" version discards information that might be important: the non-integral portion of the double. Maybe that's OK, maybe it's not -- you haven't said -- but it is the sort of mistake people often make when they let performance get ahead of correctness.)

For your particular question, the dynamic is even worse, because there's only one reason to format a string -- which is to write it out to some IO channel. IO is already way more expensive that computation, so 99.999% of the time, it doesn't really matter if a small computation on the way to an IO is 5x or 10x more expensive.

Further, much of what we "know" about performance ("I know String formatting is very expensive") is just lore, and often wrong or out of date. Be very, very suspicious about what non-experts say is "expensive".

So the answer is "don't worry, do the clear, correct, readable thing."

Brian Goetz
  • 90,105
  • 23
  • 150
  • 161
  • 1
    It’s worth noting that the question as asked doesn’t make much sense as casting and printing are two entirely different operations with different outcome. It’s only comparable if we assume an implied printing of the resulting integer number. Then, not only does the I/O dominate the performance, the printing of the integer number contains the same formatting operation, “formatting” in the sense of creating a decimal representation. It’s often overlooked by programmers that a decimal representation is not natural to a computer whether or not we use a formatting API (or an implied conversion)… – Holger Jun 29 '23 at 07:28
0

When we are talking about the performance of formatting, we mean localized formatting. That means localizing decimal separators, grouping separators etc. Imagine the usage of NumberFormatter.

However, what is expensive is not the actual formatting but the creation of the formatter because that forces the app to load rather complex Unicode information. When I say expensive, I mean it in relative terms. You would see a problem only if you try to do it hundreds of times a second.

What you are doing is just a basic number to String conversion. Nothing overly complicated. Depending on your use case you might probably save a few milliseconds by doing it differently but otherwise this is a valid solution.

Trying to improve its performance is pointless.

Sulthan
  • 128,090
  • 22
  • 218
  • 270