# Sortperm is slow (then also sortslices and sortperm); Julia's oldest performance issue(s)

**URL:** <https://discourse.julialang.org/t/sortperm-is-slow-then-also-sortslices-and-sortperm-julias-oldest-performance-issue-s/140022>\
**Category:** Performance\
**Created:** [October 14, 2026, 7:56pm UTC](https://discourse.julialang.org/t/sortperm-is-slow-then-also-sortslices-and-sortperm-julias-oldest-performance-issue-s/140022 "2026-10-14T19:56:48Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 14, 2026, 7:56pm UTC](https://discourse.julialang.org/t/sortperm-is-slow-then-also-sortslices-and-sortperm-julias-oldest-performance-issue-s/140022/1 "2026-10-14T19:56:48Z")

</div>

Continuing the discussion from [10x faster sortperm()](https://discourse.julialang.org/t/10x-faster-sortperm/93026/11):

Sortperm is at least 77.6% slower in Julia than in Python/NumPy.

Note, this is known, the next oldest performance issue (and third oldest issue from 2013):

> <https://github.com/JuliaLang/julia/issues/939>
>
> sortperm has poor performance compared to matlab.
> 
> \`\`\`
> julia\> y = collect(100…0000:-1:1);
> 
> julia\> @time sortperm(y);
> elapsed time: 0.0885950756072998 seconds
> \`\`\`
> 
> \`\`\`
> \>\> tic; \[ign, p\] = sort(y); toc
> Elapsed time is 0.030718 seconds.
> \`\`\`
> 
> \[edit - updated the issue 1/25/2012 -- ViralBShah\]

[It’s similar in speed for Float64 and Int64 as expected, but it doesn’t go much down with smaller types down to Int8 (nor much with NumPy), a bit surprising, because of radix sort?]

We are not (no longer?) “3x slower for sortperm” (as once for MATLAB in 2013, but I didn’t test it, assume it similar speed to NumPy).

I thought AI might be able to help (I could share a link to my answer), even fix if someone has access to more powerful AI than mine…

AI though SortingLab would help but it didn’t maybe in the past:

```julia-auto
using BenchmarkTools
using SortingLab

# Generate 10 million random Float64 values
const data = rand(10_000_000)

println("--- Base Julia sortperm ---")
@btime sortperm($data);

println("--- SortingLab fsortperm (Fast Radix) ---")
@btime fsortperm($data);

julia> @btime sortperm($data);
  1.980 s (6 allocations: 152.59 MiB)

--- SortingLab fsortperm (Fast Radix) ---
  1.984 s (6 allocations: 152.59 MiB

vs. Python:

import numpy as np
import timeit

# Generate 10 million random Float64 values
data = np.random.rand(10000000)

# Benchmark NumPy's argsort (defaults to Quicksort, but supports Radix/Mergesort)
t = timeit.timeit(lambda: np.argsort(data), number=3)
print(f"NumPy argsort average time: {t / 3:.4f} seconds")

NumPy argsort average time: 1.1151 seconds
NumPy argsort average time: 1.0962 seconds

```

Interestingly with as many integers (this time tested with MORE load, i.e. after starting Firefox again):

```julia-auto
rng = np.random.default_rng()
array_1d = rng.integers(0, 100, size=10000_000)

```

NumPy argsort average time: 0.5763 seconds

julia\> @btime sortperm($data);  
1.903 s (6 allocations: 152.59 MiB)

julia\> @btime fsortperm($data);  
1.911 s (6 allocations: 152.59 MiB)

```julia-auto

I haven't tested:
https://github.com/LSchwerdt/SimultaneousSortperm.jl/pull/3

The oldest (if you want to look at or "fix" the oldest and only other 3-digit performance issue):
https://github.com/JuliaLang/julia/issues/130#issuecomment-1123823801
```