Julia函数泛型类型应用的性能与最佳实践相关问题咨询

问题1 #

仅适配Int和Float的类型注解函数本身不会比无类型函数慢，性能应该和定类型版本完全一致。
你测试中Union版本性能差的核心原因是代码写得有问题：你已经用Array{T,1}固定了数组维度为1，后面where子句里额外加了未使用的N参数，属于冗余写法，会带来额外的类型推导开销。
正常情况下，只要写法正确，Array{T,1} where T<:Union{Int64,Float64}这类参数化Union注解会让Julia为Int64和Float64分别生成专用的优化原生代码，性能和单独写定类型的版本完全一致，不会和无类型版本性能相当。

问题2 #

使用Number、Real这类超类型做注解不会带来性能提升。
Julia的类型注解核心作用是控制派发、做输入合法性校验和提升代码可读性，和性能无关。只要输入参数本身是类型稳定的，不管你加不加超类型注解，Julia都会自动推导出实际参数类型，生成等效的优化代码，性能没有差异。如果输入本身类型不稳定，加任何超类型注解都不会改善性能。

问题3 #

不需要为每一种参数类型单独定义函数，这不是Julia的最佳实践，反而会造成代码冗余。
Julia的多重派发和参数化类型机制就是为了避免重复写逻辑完全一致的代码。你这个场景直接写function countMPvec(vec::AbstractArray{<:Union{Int64,Float64}})就可以同时兼容Int和Float类型的任意维度数组/向量，Julia会自动为每种实际输入类型生成最优代码，性能和单独写两个定类型版本完全一致。只有不同类型的处理逻辑存在差异时，才需要单独定义方法。

问题4 #

你可以用类型别名简化注解，不需要尝试定义抽象子类型——Julia的类型系统不支持抽象类型继承Union，这也是你报错的原因。
你只需要在代码开头定义类型别名：

const IF64 = Union{Int64,Float64}

之后就可以直接用vec::AbstractArray{<:IF64}作为参数注解，效果和写完整的Union完全一致，代码更简洁。

问题5 #

N是Julia数组类型的维度参数，Array{T,N}中的N表示数组的维度，比如N=1对应向量，N=2对应矩阵。
你代码里的N属于完全冗余的参数：你已经用Array{T,1}固定了维度是1，不需要再声明N。只有当函数需要兼容任意维度的数组时，才需要声明N参数用来匹配输入数组的实际维度。

问题6 #

内存占用差异的核心原因是其他版本的函数多了冗余的N类型参数，带来了额外的小对象分配。
你可以看到分配数刚好差了10000，和你的测试循环次数nitertest=10000完全一致：Float64版本的参数是写死的Array{Float64,1}，不需要做任何类型参数推导，调用没有额外开销；而其他带where子句的版本因为冗余的N参数，每次调用都会多做一步无用的类型匹配，产生1次小对象分配，累计下来就多了300多KiB的内存占用。
把所有函数where子句里多余的N删掉后再测试，所有正确实现的版本内存占用都会和Float64版本一致。

内容的提问来源于stack exchange，提问作者Imp54