After few days playing with the profiler I have noticed some shocking swift behaviour.When casting basic types from one type to another, for example from Int to Double swift is actually creating and then deallocating something :( That leads to another performance problem - imagine many casts in loops.
As a type strict language swift is forcing one to cast Int to Double to when you multiply double by Int variables for example but as the cast is so expensive what should developers do to get better performance for some bit of code. As a sound processing developer I see most of the real time sound processing moved to C++ code, but I don,t see the reason for that as it is most basic operations in loops. Swift needs to be faster to become serious language ...
After profiling here is what I see:
1. slow arrays - may be partly improved using UnsafeMuttablePointers
2. expensive cast - this is not possible to avoid at this point. I will suggest making the language not so type strict when there is no need (like adding int to double and so on)
array[i] = value Double(1)
These problems come from hidden function calls so please avoid adding more of them in future like the syntax Erica suggested for the if:
if v in (0...127)
I suppose that the range will be also created and then deallocated in background.
This is probably a better discussion for swift-users. It sounds like you didn't build with optimization enabled—try that before making any performance measurements.
-Joe
···
On Mar 28, 2016, at 7:05 AM, Biala via swift-evolution <swift-evolution@swift.org> wrote:
After few days playing with the profiler I have noticed some shocking swift behaviour.
When casting basic types from one type to another, for example from Int to Double swift is actually creating and then deallocating something :( That leads to another performance problem - imagine many casts in loops.
As a type strict language swift is forcing one to cast Int to Double to when you multiply double by Int variables for example but as the cast is so expensive what should developers do to get better performance for some bit of code. As a sound processing developer I see most of the real time sound processing moved to C++ code, but I don,t see the reason for that as it is most basic operations in loops. Swift needs to be faster to become serious language ...
After profiling here is what I see:
1. slow arrays - may be partly improved using UnsafeMuttablePointers
2. expensive cast - this is not possible to avoid at this point. I will suggest making the language not so type strict when there is no need (like adding int to double and so on)
array[i] = value
Double(1)
These problems come from hidden function calls so please avoid adding more of them in future like the syntax Erica suggested for the if:
if v in (0...127)
I suppose that the range will be also created and then deallocated in background.
Le 28 mars 2016 à 07:05:48, Biala via swift-evolution <swift-evolution@swift.org> a écrit :
After few days playing with the profiler I have noticed some shocking swift behaviour.
When casting basic types from one type to another, for example from Int to Double swift is actually creating and then deallocating something :( That leads to another performance problem - imagine many casts in loops.
As a type strict language swift is forcing one to cast Int to Double to when you multiply double by Int variables for example but as the cast is so expensive what should developers do to get better performance for some bit of code. As a sound processing developer I see most of the real time sound processing moved to C++ code, but I don,t see the reason for that as it is most basic operations in loops. Swift needs to be faster to become serious language ...
After profiling here is what I see:
1. slow arrays - may be partly improved using UnsafeMuttablePointers
2. expensive cast - this is not possible to avoid at this point. I will suggest making the language not so type strict when there is no need (like adding int to double and so on)
array[i] = value
Double(1)
These problems come from hidden function calls so please avoid adding more of them in future like the syntax Erica suggested for the if:
if v in (0...127)
I suppose that the range will be also created and then deallocated in background.