> Le 31 mai 2017 à 01:47, Anders Kierulf <and...@smartgo.com> a écrit : > >> >> On May 30, 2017, at 3:36 PM, Jean-Daniel via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> Le 30 mai 2017 à 12:42, Charlie Monroe via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit : >>> >>> There was someone a few weeks ago trying to port his Go game to Swift from >>> (I believe) C++ and found out that the lack of fixed-size arrays was >>> causing the move-computing algorithm to slow down significantly. >>> >>> This is due to fixed arrays being able to live on stack, while "normal >>> Array" is dynamically allocated on heap, etc. >> >> Really ? Isn’t it due to the value semantic of swift arrays ? >> >> If this is the former, its algorithm can probably be tweak to reuse the >> array and require less allocations. >> >> Unless if you algorithm is eager in memory allocation/deallocation, you >> shouldn't get a significant difference between static array and dynamic >> array. > > Eliminating the dynamic allocations and extra indirections caused by the > Swift array implementation can make a huge difference, not just in itself, > but it also gives the compiler more opportunities to optimize the code.
I don’t see how static sized array would solve that issue. If swift wants to keep value semantic it has to support COW or a similar machinery. If you want to avoid COW and force the array to be allocated on the stack, it will impose swift to copy it at each function boundary (there is no @unescape for array to tell the compiler it can safely pass a reference). If what you want is just a preallocated array with reference semantic, wrap it in a class. You should get the same speed up than when using imported C arrays.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
