为什么字符串加法需要这么长时间才能构建? [英] Why string addition takes so long to build?

问题描述

我正在UIlabel中添加文本，&它的性能成本(我使用了构建时间分析器使用此链接).我该如何优化此代码?

I am adding text in UIlabel, & its cost to performance(i have used build time analyser using this link). how can i optimise this code ?

for value in model?.offerings ?? [] {
    offeringsLabel.text = offeringsLabel.text! + " | " +  (value.name ?? "") + "," +  (value.type ?? "")//this addition cost to performance
}

我也尝试过[ array].joined，但这并没有造成任何差异

I also tried [ array].joined but that doesn't make any diffrence

推荐答案

首先，解决基本问题.为什么这么慢?根据我的经验，链接+是导致大量编译时性能问题的最常见原因.这是因为+有很多重载(我在4.2的stdlib中计算为103). Swift并不仅需要证明+可以按需在(String, String)上使用.它必须证明没有其他可能的同等有效的重载组合(如果存在，那将是模棱两可的，并且是一个错误).这不仅包括简单的情况，例如(Int，Int).它还包括适用于(String，String)的复杂的基于协议的重载，但不如(String，String)那样精确:

First, to the underlying question. Why is it slow? Chained + is the single most common cause of massive compile-time performance issues in my experience. It's because + has a lot of overloads (I count 103 in 4.2's stdlib). Swift doesn't just have to prove that + can be used on (String, String) as you want it to be. It has to prove there is no other possible overload combination that is equally valid (if there were, it'd be ambiguous and an error). That doesn't just include simple cases like (Int, Int). It also includes complicated protocol-based overloads that apply to (String, String), but aren't as precise as (String, String) like:

static func + <Other>(lhs: String, rhs: Other) -> String 
    where Other : RangeReplaceableCollection, Character == Other.Element

这需要很长时间，因为当您将一堆+链接在一起时，它具有爆炸性.必须根据可能返回的所有内容重新考虑每个子表达式.

This takes a long time because it's combinatorially explosive when you have a bunch of + chained together. Each sub-expression has to be reconsidered in light of everything it might return.

如何解决?首先，在这种情况下，我不会使用for循环来逐步构建一个字符串.只需map每个Offering到所需的字符串，然后将它们连接在一起即可:

How to fix it? First, I wouldn't use a for loop in this case to build up a string piece by piece. Just map each Offering to the string you want, and then join them together:

offeringsLabel.text = model?.offerings
    .map { "\($0.name ?? ""),\($0.type ?? "")" }
    .joined(separator: " | ")

这不仅可以更快地编译，而且IMO更加清楚了您在做什么.它还不需要!，这很好. (还有其他方法可以解决此问题，但这是一个很好的副作用.)

Not only will this compile much more quickly, but it's IMO much clearer what you're doing. It also doesn't require a !, which is nice. (There are other ways to fix that, but it's a nice side-effect).

也就是说，这也表明您的模型中可能存在问题.这是一个单独的问题，但我仍然会认真对待.任何时候只要您的代码如下:

That said, this is also pointing to a probable issue in your model. It's a separate issue, but I would still take it seriously. Anytime you have code that looks like:

optionalString ?? ""

您需要问，这真的是可选的吗?您真的将nil名称与空名称区别对待吗?如果没有，我相信name和type应该只是String而不是String?，然后这变得更加简单.

you need to ask, should this really be Optional? Do you really treat a nil name differently than an empty name? If not, I believe that name and type should just be String rather than String?, and then this gets even simpler.

offeringsLabel.text = model?.offerings
    .map { "\($0.name),\($0.type)" }
    .joined(separator: " | ")

此代码与您的代码略有不同.当model为nil时，您的代码将单独离开offeringsLabel.我的代码清除了文本.这就提出了一个更深层的问题:当model为nil时，为什么还要运行此代码?为什么model是可选的?您是否可以使它在数据中成为非可选，还是应该在此方法的前面加上guard let model = model else { return }?

This code is has a slight difference from your code. When model is nil, your code leaves offeringsLabel alone. My code clears the text. This raises a deeper question: why are you running this code at all when model is nil? Why is model optional? Could you either make it non-optional in the data, or should you have a guard let model = model else { return } earlier in this method?

在我的经验中，Swift过于复杂的常见原因是对Optional的过度使用.可选的功能非常重要且功能强大，但是除非您真正的意思是完全没有价值是合法的，而且不同于'空'，否则您不应该使用它."

The common cause of over-complicated Swift in my experience is the over-use of Optional. Optional is incredibly important and powerful, but you shouldn't use it unless you really mean "having no value at all here is both legitimate, and different than just 'empty'."

这篇关于为什么字符串加法需要这么长时间才能构建?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！