# How to make splat, map and tuples be efficient

**URL:** <https://discourse.julialang.org/t/how-to-make-splat-map-and-tuples-be-efficient/125653>\
**Category:** Performance\
**Tags:** tuple, map, splat\
**Created:** [February 7, 2025, 12:07pm UTC](https://discourse.julialang.org/t/how-to-make-splat-map-and-tuples-be-efficient/125653 "2025-02-07T12:07:48Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![garazha-ilya](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/garazha-ilya/32/214384_2.png) [@garazha-ilya](https://discourse.julialang.org/u/garazha-ilya)\
**Post date:** [February 7, 2025, 12:07pm UTC](https://discourse.julialang.org/t/how-to-make-splat-map-and-tuples-be-efficient/125653/1 "2025-02-07T12:07:48Z")

</div>

Generally I want to make

```julia
f(g("a"), g("c"), g("k"))

```

with

```julia
f(map(g, ["a","c","k"])...)

```

be efficient and don’t generate allocations.

And I started experimenting, by creating 3 functions:

```julia
function foo_tuple(a,b,c)
       +((a+1,b+2,c+3)...)
end

function foo_arr(a,b,c)
       +([a+1,b+2,c+3]...)
end

function foo(a,b,c)
       +(Tuple(i+j for (i,j) in zip(1:3,(a,b,c)))...)
end

```

Benchmarks are below:

```julia-REPL
julia> @btime foo(1,2,3)
  247.813 ns (2 allocations: 112 bytes)
12

julia> @btime foo_arr(1,2,3)
  93.243 ns (1 allocation: 80 bytes)
12

julia> @btime foo_tuple(1,2,3)
  1.600 ns (0 allocations: 0 bytes)
12

```

And now I have several questions:

1. Is there an efficient way to make map return tuple?
2. How can I create tuples from arrays efficiently? `Tuple([1,2,3])` is 150 times slower than `tuple(1,2,3)`

I know, that splat isn’t preferable tool for big number of arguments, but with [RGBA](https://github.com/JuliaGraphics/ColorTypes.jl) it will be cool to know how to pass parameters with this. ☺

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [February 7, 2025, 12:18pm UTC](https://discourse.julialang.org/t/how-to-make-splat-map-and-tuples-be-efficient/125653/2 "2025-02-07T12:18:32Z")

</div>

> [@garazha-ilya](#):
>
> Is there an efficient way to make map return tuple?

Pass a tuple to map 🙂  
As in, `f(map(g, ("a","c","k"))...)`.

> [@garazha-ilya](#):
>
> How can I create tuples from arrays efficiently? `Tuple([1,2,3])` is 150 times slower than `tuple(1,2,3)`

Either of these is efficient:

```julia
v = [1,2,3]
Tuple{Int,Int,Int}(v)
NTuple{3,Int}(v)

```

---

<div class="post-metadata">

**Author:** ![abraemer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/abraemer/32/51403_2.png) [@abraemer](https://discourse.julialang.org/u/abraemer)\
**Post date:** [February 7, 2025, 6:50pm UTC](https://discourse.julialang.org/t/how-to-make-splat-map-and-tuples-be-efficient/125653/3 "2025-02-07T18:50:01Z")

</div>

To add an explanation to this:  
The main difference (from the compiler’s perspective) between `[1,2,3]` and `(1,2,3)` is that the `Tuple` knows how many elements there are (and their types) while the `Vector` only preserves the type of its elements. So creating a `Tuple` from a `Vector` is inherently a type-unstable operation as there is no way to infer the length of resulting tuple from the `Vector`’s type information. Splatting arguments into a function call essentially reduces to constructing a tuple of all arguments.  
So when splatting a `Vector` into a function, the compiler cannot know how many arguments there will be, so Julia needs to check at runtime.

---

<div class="post-metadata">

**Author:** ![Domenico\_Lahaye](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/domenico_lahaye/32/203728_2.png) [@Domenico\_Lahaye](https://discourse.julialang.org/u/Domenico_Lahaye)\
**Post date:** [February 7, 2025, 7:08pm UTC](https://discourse.julialang.org/t/how-to-make-splat-map-and-tuples-be-efficient/125653/4 "2025-02-07T19:08:29Z")

</div>

Thx. Much appreciated.