I've never seen the Swift compiler put array storage on automatic storage, even for small arrays. I don't think that it has much to do with their size, though (for any array that is not incredibly large).
> Le 3 août 2017 à 23:18, David Hart <[email protected]> a écrit : > > Don’t small arrays live on the stack? > >> On 4 Aug 2017, at 06:35, Félix Cloutier via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> As far as I can tell, currently, all arrays live on the heap. >> >>> Le 3 août 2017 à 19:03, Robert Bennett via swift-evolution >>> <[email protected] <mailto:[email protected]>> a écrit : >>> >>> Where do constant Arrays currently live? I hope the answer is on the stack, >>> since their size doesn’t change. >>> >>> On Aug 3, 2017, at 8:44 PM, Taylor Swift via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> >>>> >>>> On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> The root cause, of course, is that the VLAs require new stack >>>>>> allocations each time, and the stack is only deallocated as one lump >>>>>> when the frame ends. >>>>> >>>>> That is true of alloca(), but not of VLAs. VLAs are freed when they go >>>>> out of scope. >>>>> >>>> >>>> Learned something today. >>>> >>>> Anyway, if the goal is stack allocation, I would prefer that we explored >>>> other ways to achieve it before jumping to a new array-type. I’m not >>>> really a fan of a future where [3; Double] is one type and (Double, >>>> Double, Double) is something else, and Array<Double> is yet another thing. >>>> >>>> They are completely different things. >>>> >>>> [3; Double] is three contiguous Doubles which may or may not live on the >>>> stack. >>>> >>>> (Double, Double, Double) is three Doubles bound to a single variable name, >>>> which the compiler can rearrange for optimal performance and may or may >>>> not live on the stack. >>>> >>>> Array<Double> is an vector of Doubles that can dynamically grow and always >>>> lives in the heap. >>>> >>>> >>>> From what I’ve read so far, the problem with stack-allocating some Array >>>> that you can pass to another function and which otherwise does not escape, >>>> is that the function may make an escaping reference (e.g. assigning it to >>>> an ivar or global, or capturing it in a closure). >>>> >>>> How about if the compiler treated every Array it receives in a function as >>>> being potentially stack-allocated. The first time you capture it, it will >>>> check and copy to the heap if necessary. All subsequent escapes (including >>>> passing to other functions) use the Array known to be allocated on the >>>> heap, avoiding further checking or copying within the function. >>>> >>>> The same goes for Dictionary, and really any arbitrary value-type with COW >>>> storage. The memory that those types allocate is part of the value, so it >>>> would be cool if we could treat it like that. >>>> >>>> >>>> This is not true. FSAs have nothing to do with automatic storage, their >>>> static size only makes them eligible to live on the stack, as tuples are >>>> now. The defining quality of FSAs is that they are static and contiguous. >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
