斯威夫特的数据结构和算法_斯威夫特:结构vs班级表现

斯威夫特的数据结构和算法

While doing iOS development, you must have faced a situation where you need to select between Class Vs Struct. How did you decide to choose between those? Well, we take some consideration while choosing:

在进行iOS开发时,您必须面对需要在Class Vs Struct之间进行选择的情况。 您是如何决定在这些之间进行选择的? 好吧,我们在选择时要考虑一些因素:

  1. Do we need value type OR reference type?

    我们需要值类型还是引用类型?
  2. Do we need to support inheritance?

    我们需要支持继承吗?

Most of us take the above 2 considerations while choosing between Struct and Class. But what about the performance of them? Did you consider the following facts too:

我们大多数人在Struct和Class之间进行选择时会考虑上述两个注意事项。 但是它们的性能如何? 您是否也考虑以下事实:

  1. Which one in Struct and Class is faster?

    Struct和Class中哪一个更快?
  2. Which is more optimized in memory?

    哪个在内存上更优化?
  3. Which is Faster?

    哪个更快?

Well in this blog I will be majorly focusing on performance and memory management of Struct and Class.

在本博客中,我将主要关注Struct和Class的性能和内存管理。

结构和类之间的性能和内存管理: (Performance and Memory management between Struct and Class:)

When it comes to performance, we should always consider facts that:

在性能方面,我们应始终考虑以下事实:

Value type is faster than reference type because they store in Stack and reference type store in Heap. So storing in Heap if more time consuming process. Also while storing reference type, we have one more burden to manage retain count of that object.

值类型比引用类型快,因为它们存储在Stack中,而引用类型存储在Heap中 。 因此,如果需要更多时间,则将其存储在堆中。 同样,在存储引用类型的同时,我们还有另一个负担来管理该对象的保留计数

So based on the above theory we can say that Struct is faster than Class because:

因此,根据以上理论,我们可以说Struct比Class快,因为:

  1. To store class, Apple first finds memory in Heap, then maintain the extra field for RETAIN count. Also, store reference of Heap into Stack. So when it comes to access part, it has to process stack and heap. See below example image from Apple video:

    为了存储类,Apple首先在Heap中找到内存,然后为RETAIN计数保留额外的字段。 另外,将堆的引用存储到堆栈中。 因此,当涉及到访问部分时,它必须处理堆栈和堆。 请参阅下面的Apple视频示例图片:

So if you look at Image, to store a Class we have:

因此,如果您查看Image,要存储一个Class,我们有:

  • Stack to store heap reference

    堆栈以存储堆参考
  • Heap to store class variable x and y.

    堆存储类变量x和y。
  • One extra field to maintain retain count for that class.

    一个额外的字段来维护该类的保留计数。

So you can take the fact that in this case if you want to access class variables, it has to look stack and heap both.

因此,您可以得出这样的事实:在这种情况下,如果要访问类变量,则必须同时查看堆栈和堆。

2. Now if we talk about Struct, It just uses Stack to store values, so while reading value we just read directly from the stack in O(1) time. Look below example using Stack where we need to store x and y.

2.现在,如果我们谈论Struct,它只是使用堆栈来存储值,因此在读取值时,我们只是在O(1)时间内直接从堆栈中读取。 看下面使用Stack的示例,我们需要在其中存储x和y。

Image for post

So if you look above example, this is the same as class one but here we don’t need any Heap. So 2 points here:

因此,如果您看上面的示例,它与第一类相同,但是在这里我们不需要任何堆。 所以这里有2点:

  • No heap is used while using struct

    使用结构时不使用堆
  • Assigning to another stack variable create another copy

    分配给另一个堆栈变量创建另一个副本

So based on the above thing, we can say that Struct always performs fast then class. But wait if that is the case:

因此,基于以上内容,我们可以说Struct总是执行得那么快。 但是,如果是这种情况,请等待:

  • Why do we need class if they slow then struct?

    如果他们慢然后构造,为什么还要上课?
  • Is struct always fast then class?

    结构总是快然后上课吗?

Well, there is a situation where struct can be too costly for you. Consider a case where your struct contains lots of reference type variables, eg String. So we have an issue here:

好吧,在某些情况下,结构对于您来说可能太昂贵了。 考虑一下您的结构包含大量引用类型变量(例如String)的情况。 所以我们这里有一个问题:

  • Swift always store reference type into the heap, so all reference types will be store into the heap.

    Swift总是将引用类型存储在堆中,因此所有引用类型都将存储在堆中。
  • Struct behavior, if we pass struct within 8–10 methods and classes, what will happen? Well if we talk about struct behavior it should create so many heap allocations, since assigning struct will create a copy. But does the apple really do like this? The answer is NO. Here we come to an approach Copy on Write. Let’s look at what it is.

    结构行为,如果我们在8-10个方法和类中传递struct,将会发生什么? 好吧,如果我们讨论结构行为,它应该创建这么多堆分配,因为分配结构会创建一个副本。 但是苹果真的真的这样吗? 答案是否定的 。 在这里,我们来谈谈写时复制的方法 让我们看看它是什么。

写时复制: (Copy On Write:)

In a situation where we have so many reference types store into the struct, Apple creates a copy of struct only when we modify some property of struct. So let’s understand by example:

在我们将大量引用类型存储到struct的情况下,Apple仅在修改struct的某些属性时才创建struct的副本。 因此,让我们通过示例来了解:

So if we look at the above example, we assigned one object of Employee to another object. So do you think there is a copy created into memory? Well, the answer is a big NO here.

因此,如果我们看上面的示例,我们将Employee的一个对象分配给了另一个对象。 那么,您是否认为已在内存中创建了一个副本? 好吧,答案是否定的

As per apple, they create copy only if we modify some property of employee2 object. This is to optimize memory to be wasted, so just copy all slots only when any object is modifying.

对于每个苹果,仅当我们修改employee2对象的某些属性时,它们才会创建副本。 这是为了优化浪费的内存,因此仅在修改任何对象时才复制所有插槽。

Image for post

The above image is from the Apple WWDC video, where they clearly mention that if we just assign struct variables, it keeps pointing to the same heap until any modification is not made.

上面的图片来自Apple WWDC视频,他们清楚地提到,如果我们只分配结构变量,它将一直指向同一堆,直到未进行任何修改为止。

So the decision between Struct and Class can be taken by considering the above facts. If Struct has lots of reference types and we need to mutate lots of objects then the class may be helpful in this case. But again it depends on a case by case.

因此,可以通过考虑以上事实来做出Struct和Class之间的决定。 如果Struct有很多引用类型,并且我们需要对很多对象进行突变,那么在这种情况下该类可能会有所帮助。 但这又要视情况而定。

深度更多: (More in Depth:)

If you haven’t got a chance to look apple WWDC video, I am adding a screenshot for one more example, how we can improve performance in our app. Idea is to avoid multiple instances creation of reference type.

如果您没有看苹果WWDC视频的机会,我将添加另一个示例的屏幕快照,以了解如何提高应用程序的性能。 想法是避免创建引用类型的多个实例。

Image for post

If we look at the above example:

如果我们看上面的例子:

It has an image map where the key is a string. So if you take an example if a table view where for each cell we either need to download OR get from the cache. So whatever is the case, but we keep calling make balloon function which keeps creating string key. So now you must be aware of how costly is to create reference type.

它具有一个图像映射,其中的键是一个字符串。 因此,如果以表视图为例,我们需要为每个单元下载或从缓存中获取每个单元的位置。 所以无论如何,但我们一直在打电话给make Balloon 不断创建字符串键的函数。 因此,现在您必须知道创建引用类型的代价。

So Apple suggested that we should avoid these cases as much is possible to improve app performance.

因此,苹果建议我们应尽可能避免这些情况,以提高应用程序性能。

Above example can be solved in the following way:

上面的示例可以通过以下方式解决:

Image for post

Instead of String as key, Now we has a struct Attributes as key. So creating struct variable is not time consuming process. So this will help to improve performance a lot.

现在我们将struct Attributes作为键,而不是将String作为键。 因此,创建结构变量不是耗时的过程。 因此,这将大大提高性能。

This is the end of this article, so based on the above facts we should always be very careful while choosing between Reference Type and Value Type.

这是本文的结尾,因此基于上述事实,在引用类型和值类型之间进行选择时,我们应始终非常小心。

翻译自: https://medium.com/macoclock/swift-struct-vs-class-performance-29b7be73d9fd

斯威夫特的数据结构和算法

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值