# Limitation in Union types with CUDA.jl?

**URL:** <https://discourse.julialang.org/t/limitation-in-union-types-with-cuda-jl/76494>\
**Category:** GPU\
**Created:** [February 15, 2022, 4:32pm UTC](https://discourse.julialang.org/t/limitation-in-union-types-with-cuda-jl/76494 "2022-02-15T16:32:25Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![jling](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jling/32/212909_2.png) [@jling](https://discourse.julialang.org/u/jling)\
**Post date:** [February 15, 2022, 5:21pm UTC](https://discourse.julialang.org/t/limitation-in-union-types-with-cuda-jl/76494/2 "2022-02-15T17:21:57Z")

</div>

it’s the same thing as:

> [@Strange way to recover performance with polymorphic types](https://discourse.julialang.org/t/strange-way-to-recover-performance-with-polymorphic-types/72250):
>
> This is a followup of [dramatic performance change by adding additional unused method](https://discourse.julialang.org/t/dramatic-performance-change-by-adding-additional-unused-method/71771). The explanation was the existing limit on the number of overloaded methods the Julia optimizer is looking to decide the actual return type at compile type. I have found a way to avoid the allocation problem and recover the performance. The reproducer code is using BenchmarkTools using StaticArrays const Vector3 = SVector{3,Float64} abstract type AbstractShape end struct Box \<: AbstractShape x::Float64;…

> [@Dramatic performance change by adding additional unused method](https://discourse.julialang.org/t/dramatic-performance-change-by-adding-additional-unused-method/71771/5):
>
> [https://github.com/JuliaLang/julia/blob/96902377bde0b3e84c1319e0d5ad55039610d5ef/base/compiler/types.jl#L69](https://github.com/JuliaLang/julia/blob/96902377bde0b3e84c1319e0d5ad55039610d5ef/base/compiler/types.jl#L69)

right?

---

_[View the full topic](https://discourse.julialang.org/t/limitation-in-union-types-with-cuda-jl/76494)._